i^5943 


P0ST8HAD1 

l^lonterey,  California 


Ul 


T 


A  PRJELIMINARY  DDS  DESIGN  FOR  SPLICE 
BASED  UPON  THE  T.^NDEM  DBMS 


oy 


David  C.  Ruff 
James  R.  Johnscn 

March  19  84 


Thesis  Advisor: 


Dan  Dolk 


Approved  for  public  release;  distribution  unlimited 


T215681 


SECURITY  CLASSIFICATION  Of  THIS  f»AOE  Ot^an  Dmim  Enlmrud) 


RgPCRT  DOCUMENTATION  PAGE 


2.  GOVT  ACCESSION  NO 


4.     TITLE  (tnd  Subttila) 

A   Preliminary  UDS  Design  for  SPLICE 
based  upon  the  T.\NDEM  DBMS 


7.  A\jTHOm(a) 

Ruff,  David  C. 
Johnson,  James  R. 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


3.      RECIPIENT'S  CATALOa   rJOMaER 


S.     TYPE   OF   REPORT   t,    P  £  PI  O  0  COVERED 

Master ' s  Thesis 
March  19  84 


6.  PERFORMING  ORG.  REPORT  NUMBER 


8.  CONTRACT  OH  GRAKT  NUMBERr*; 


>.     ^CnrORMING  O'tQANIZATION  NAME  AND  ADDRESS 

Naval  Postgraduate  School 
Monterey,  CA  9  5943 


10.     PROGRAM    Ei.EMENT,  PROJECT.    TASK 
AREA   a    »rO>*K   UNIT   NUMBERS 


1  I.     CONTROLLING  O^riCC  NAME   AND  ADDRESS 

Naval  Postgraduate  School 
Monterey,  CA  9  5943 


12.     REPORT   DATE 

March    19  84 


U.     MONITORING  AGENCY   NAME  ft    AODRESS('(i  dllttrttl  trom  Controlilna  Oltlc*) 


13.      NUMBER  OF   PAGES 

ZJ3 


IS.      SECURITY   CLASS,    fot  ttiit  r»portj 


UNCLASSIFIED 


15*.      DECLASSIFICATION     DOWNGRADING 
SCHEDULE 


1«.     OlSTRIi'jTlON   STATEMENT  (et  thi t  R»porl) 

Approved  for  public  release;  distribution  unlimited 


17.     DISTRIBUTION  STATEMENT  (ol  tht  mo»trm<t  ■n(«r«d  in  3toek  30.  II  illtmrant  from  Rmpori} 


It.    surrlementary  notes 


l>      <£y  WORDS  (Canilnu*  on  fvt»m  aid*  //  n«c««aarr  and  Idantlty  by  bloat  numbmt) 


SPLICE,  DDS ,  data  dictionary/directory  system,  information 
resource  management,  database  design 


20      ABSTRACT  fConllmjt  an  rrnvmram  tidm  It  nmem»»ary  tnd  letanilty  by  b/ock  numbmr) 

This  thesis  considers  a  Data  Dictionary/Directory  System  (DD 
the  Stock  Point  Logistics  Integrated  Communications  Environm 
(SPLICE)  project  using  the  TANDEM  DBMS  package.   The  thesis 

gives  a  background  on  SPLICE,  then  describes  the  concept  of 
Di c ti onary / Di re c to ry  Systems.   In  the  coming  age  of  informat 
resource  management,  DDSs  will  increasingly  become  an  import 
management  tool  of  the  database  administrator.   Highlights  o 
DDS  facilities  are  mentioned  as  are  design  and  distribution 


S)  for 
en  t 
f  i  rs  t 

Data 
i  on 
an  t 
f  the 
con- 


.^U. 


JUA. 


I 


DO     I   JAM   71     1473  COITION  0?    <  MOV  •»  IS  OBSOLETE 

S    N   0102-  LF-  014-  6601 


SECURITY   CLASSIFICATION   O^    THIS  PAGE   r»h»n   Data   tniaf 


Apprcvea   fcr   public   release;    distributicr.    nnlimi-^ed 

A  Prelialrary   DDS   Eesigii   for   SPLICE 
Bas€<3    Upon    the    TANDEM    DBMS 

by 

David  C.  Buff 
Lieutenant,  UnitsS  States  Navy 
B.B.A.,  University  of  Mississippi,  1976 

an  d 

James    R.    Johnson 
Captain,    United    States    Marine    Cores 
B.A.,    Central   Washington   University. '  1975 
M.B.A,,    National    University,     1981 

Submitted    in   partial   f ulf ilLnent   of   the 
requirements    for   the    degree    of 

MASTER    OF    SCIENCE    IN    INFORMATION    SYSTEMS 

from   the 


NAVAL  POSTGRADUATE  SCHOOL 
March  1984 

— a^ . ._   ,^  // 


N.V 

MO 


CiiLltQRUIA   95943 


A2STBaCT 


Ihis      thesis  considers      a      Data    Dictionary/Directory      Systsm 
(DDS)  for        the         Stock  Pcint        Logistics         Integrated 

Communicaticns  Envircr.ment  (SPLICE)  project  using  the  tancsm 
EBHS  package.  The  thesis  first  gives  a  backcrcund  or. 
SPLICE,  then  describes        the  concept  of  Data 

Dicticnary/Director y  Systems.  In  the  coming  age  of  infcrnria- 
tion  rescurce  manageicent,  DDSs  will  increasingly  become  an 
important  management  tool  of  the  database  administrator. 
Highlights  cf  the  DDS  facilities  are  mentioned  as  are  design 
and    distribution  considerations. 
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I-     SPLICE    A]JD    THE    DATA    DICTION ARY/DIRSCTORY    SYSTJ^ 

A.       EACKGEODND 

The  purpose  of  the  Stock  Point  Logistics  Integrated 
Comniunica-^icns  Environment  (SPLICE)  is  to  provids  an  -snvi- 
rcnment  to  effectively  and  efficiently  support  the  interac- 
tive and  telecommunications  requirements  of  all  current  and 
new  projects  operating  within  the  Navy  Unifcrii  Automated 
Data  Processing  System  for  Stock  Points  (UADPS-SP) .  The 
Uaval  Supply  Systems  Command  (NAVSUP)  is  th<=  project  sponsor 
for  SPLICE  with  the  CADPS-S?  sites  being  the  primary  us9rs 
along  with  ether  Department  of  Defense  (DoD)  /  Navy  systems. 
[Ref.    1] 

NAVSDP  initiated  the  SPLICE  project  to  consolidate  the 
telecommunications  requirements  of  several  different 
projects,  in  various  stages  of  design,  which  will  impact  all 
of  the  Navy  UADPS-SP  sites  [Ref.  2].  (See  list  of  projects 
which  follows  this  section.)  Implementation  of  SPLICE  is 
expected   to    provide    the   following  capabilities: 

•  sign- on   security 

•  CRT/terminal   management 

•  screen   formatting 

•  edit,    validation  and  correction 

•  fault-tolerant    operation 

•  data   communications   front   end 

•  processing    with   menu   capability 

•  interactive  transaction  entry 

•  access   to    database   management   systems 

SPLICE  will  consclidate  the  telecommunications  network 
with  a  standard  suite  of  hardware  and  software.  The  SPLICE 
concept    involves   the      use   of  a    single      minicomputer   hardware 


and  software  suits  ir.  conjunction  with  tha  existing  UADtS-SP 
Burroughs  system.  The  SPLICE  mini computers  are  intenisd  to 
absort  and  contain  ths  communications  handling  workload  that 
is  currently  forcing  the  host  Burroughs  CPU's  into  satura- 
tion. The  SPLICS  concept  calls  for  standard  minicomputers 
to  be  ecplcyed  as  foreground  processors  at  each  UADPS-S? 
site  and  interfaced  via  a  high  speed  data  network  (HSDN)  to 
the  E'cricughs  medium  size  system.  The  foreground  miniccm- 
puter  will  handle  communication  lines  and  terminal  nanace- 
ment,  support  interactive  operations  and  stage  m^^ssages  for 
the  background  processors.  The  Burroughs  background  systems 
will  handle  large  file  processing  applications,  report  prep- 
aration, batch  processing  and  data  base  management 
functions. 

SPLICE  will  utilize  a  standard  minicomputer  and  a 
modular  software  desicn.  A  modular  set  of  embedded  computer 
software  components  will  provide  flexibility  in  that  the 
configuration  of  each  site  within  the  SPLICE  network  can  be 
designed      to     meet      its   unique      requirements.  The      SPLICE 

configuration  will  consist  of  multiple  processors  with 
shared  resources.  A  SPLICE  configuration  may  interface  with 
one  or  more  mainframes,  function  as  a  satellite  off  another 
SPLICE  complex,  or  function  as  a  s-^and  alone  system 
[Ref.  3].  Within  the  SPLICE  network,  each  terminal  and 
computer  process  in  the  systeir  can  potentially  access  any 
ether   terminal    and    computer    process. 

A  common  element  within  the  SPLICE  system  is  the  use  of 
CRT's  to  provide  interactive  processing  capabilities  for  a 
"user  oriented  system."  The  C?.T  display  terminals  will 
interact  with  the  application  logic  and  fetch  information 
from  system  data  bases.  The  current  stock  point  system  does 
Dot  support  interactive  processing  nor  does  it  have  the 
capacity  to  add  a  najor  increase  in  terminal  support  or 
associated    processing  requirements. 


The  design  philcscphy  reinforced  throughout  th?-  SPLICZ 
project  will  be  device  independent  management  capability. 
No  application  program  will  read  or  write  directly  to  or 
from    a      particular    device.  The   driving      force    behind      the 

SPLICE  project  is  the  need  to  provide  computer  and  comrruni- 
cations  interfaces  for  the  irany  application  initiatives 
which  cress  boundaries  of  tasking  and  funding  of  many  Navy 
major  claimants  [Ref.  2].  Projects  that  are  to  be  tied  to 
DADFS-S?   under    the    SPLICE   project  are: 

•    Automation      of    Procurement      and      Accounting    Data      Entry 

(APADE) 

Centralized  Accounting  and  Billing  (CAB) 

Closed  Loop  Aeronautical  Management  Program  (CLAMP) 

Eisk  Oriented  Supply  System  (DOSS) 

Fixed   Alllowance   Management    and   Monitoring   System 

(FAMMS) 

Finencial  Improvement  Program  (FI?) 

Integrated  Disbursing  and  Accounting  (IDA) 

Multiple  Activity  Processing  System  (MAPS) 

Kanagement  Information   System  International   Logistics 

(MISII) 

Navy   Automated   Transportation   System    (NATDS) 

Navy      Automated      Transportation         Documentation      System 
(NAVADS) 

Navy   Standard   Civilian    Payroll    System    (NAVCIPS) 

On   line   Autodin     (CLA) 

Operating   Target   Accountirg   for   TRIDENT    (QPTAR) 

Receipt  Improvement   Project    (RIP) 

TRIEENT  submarire   Logistics   Data    System    (TRIDENT    LDS) 

Requisition  Monitoring    and   Material   Expediting    (RM8ME) 
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E-   NATOEE  CF  THE  PECELEM 

.  Besearch  and  thesis  work  en  th9  SPLICE  project  thus  far 
has  primarily  emphasized  t elecommanicat-ions  and  local  area 
network  (LAN)  design  within  the  SPLICE  project  [Hef.  4]. 
Eecause  of  -^he  nature  of  the  project  and  the  extent  of  its 
future  iirpact  on  other  DoD/Navy  systems,  SPLICE  should  also 
te  locked  at  as  an  environment  which  calls  for  the  applica- 
tion cf  a  Data  Dictionary/Directory  System  (DDS)  zo  fullfill 
its  expectations. 

C.  OEJECTIVE 

TflNEiM  has  teen  selected  as  the  minicomputer  of  choice 
for  the  SPLICE  project.  As  a  result,  the  objective  of  this 
thesis  to  suggest  a  preliminary  DDS  design  for  SPLICE  iased 
upon    the    TANDEM    DBMS. 

D.  HITHCDOIOGI 

This  thesis  will  look  at  the  current  state  of  the  SPLICE 
EDS  and  what  an  active  DDS  can  do  for  the  SPLICE  project. 
It  will  Icck  at  methods  to  evalua-e  a  DDS  and  apply  these  to 
the  EES  design.  DDS  design  considerations  within  the  SPLICE 
environment  will  be  identified,  such  as  which  resources  need 
to  be  represented  in  the  DDS,  and  to  the  extent  possible, 
integrated  into  the  recommended  proposal.  In  the  process, 
Guesticns  on  the  distribution  of  the  DDS  within  SPLICE  will 
also  te  addressed  with  recommendations  for  selection  of  the 
format  which  is  most  beneficial  to  the  objectives  of  the 
SPLICE   project. 
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II.    DATA    PI CTIO jil ARY/fDI  BSCTOE Y    SYSTEM    CONCEPTS    A^D 

CONS  IDE PATIONS 

1-       INTBCDOCTIOH 

Data  is  a  very  useful  and  necessary  resource  to  an  crca- 
nizaticn.  Data  is  a  ceneral  term  used  to  express  any  or  all 
facts,  numbers,  letters,  and  symbols  tha-  refer  tc  or 
describe  an  object,  idea,  condition,  situation  or  ether 
factor.  It  can  be  used  to  influence  management  decisions, 
by  providing  the  marager  with  timely  and  accurate  informa- 
tion. With  these  thoughts  in  mind,  it  is  very  important  that 
data  as  a  resource  be  easily  accessible  for  proper  and 
effective      management. 

The  early  design  of  Navy  data  processing  sysiems 
revolved  around  specific  application  systems  (UADPS-SP)  , 
hence  the  data  was  organized  so  that  it  would  be  machine  and 
application   specific.  Therefore   the      data    seldom      crossed 

operational,  functional  or  organizational  boundaries.  The 
outcome  of  this  early  design  was  multiple  definitions  of  the 
same  data  as  individual/independent  data  files  were 
generated   creating    much   redundancy   and  overlap. 

As  the  role  of  the  computer  has  grown  in  the  Navy  Supply 
SysreiD,  the  need/requirement  for  system  integration  has 
tecome  evident,  especially  in  the  area  of  data.  The  intro- 
duction of  Database  Management  Systems  (DBMS)  solves  many  of 
the  information  resource  problems  by  organizing  the  data 
elements  under  consistent  controls  and  structures,  by 
providing  a  single  flexible  facility  for  accommodating 
different  data  files  and  operations,  and  demanding  less 
programming   effort    than   conventional    programming    languages. 
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This  c€ntralizat  icn  cf  ccntrcl  is  growing  in  acc  =  p-ar.c^ 
and  th*  function  cf  iirplementing  this  centralized  centre!  is 
in  th€  hands  of  -he  Database  Administrator  (DBA)  [Esf.  5]. 
The  data  administration  function  is  responsible  for  -h- 
sysrsiD  wide  inventory  and  control  of  data.  It  r«=quires 
pertinent  facts  and  relationships  about  the  varying  data 
elem<=Et£,  processes,  users  and  equipment  to  be  lccat«d  in 
the  data-processing  environment  [Ref.  6].  Data  administra- 
tion internal  ccntrcl  procedures  restrict  access  to  data, 
canage  development  of  new  types  of  data,  and  protect  data 
from    errcneous    update  and  system    failure. 

A  software  tool  that  is  used  to  contrcl  and  manage  data 
elemerts  in  a  uniform  manner  and  is  therefore  an  aid  tc  the 
IBA  is  the  Dictionary/Directory  System  (DDS)  .  The  DDS  can 
serve  Database  Administrators,  system  analysts,  sof-^ware 
designers,  and  programmers  by  providing  a  central  repository 
for  information  about  data  resources  across  organization  and 
application   lines.  It  is    a   set      of   one   or      more   databases 

containing  data  about  an  organization's  information 
resources  which  can  be  retrieved  and  analyzed  using  standard 
database         management      system        capabilities,  (i.  e.  ,  query 

languages,    processors)    [Bef-    7]. 

The  lange  of  information  which  can  be  held  in  a  DDS  is 
very  large.  The  simplest  system  may  only  hold  sufficient 
informaticn  to  document,  say,  COBOL  file  structures.  The 
lore  coioplex  systems  may  hold  design  requirements,  designed 
database  structures,  possible  future  structures,  operational 
information,  extensive  details  cf  access  to  data,  and  even 
netwcrk      specif icaticns.  Such    complex      systems      initially 

build  arcund  data  structure  recording  facilities,  but  once 
developed,  are  really  the  data  processing  departments'  cwn 
database   [Ref.    8  ]. 

The  primary  advantages  of  a  well  designed  DDS  which  are 
applicable    to   SPLICE    are: 


13 


•  It  cor.tains  a  uriqua  identification,  a  set  of  physical 
characteristics,  and  a  textual  dascription  for  €ach  of 
the   data   elsmsnts, 

•  It  shovis  tha  reflation  ships  of  elements  to  each  other, 
and  tc    components   of  tha    system. 

•  It  specifies  the  source,  location,  usage  and  destina- 
tion  of  the   elements. 

•  It   has    validaticn   ana    redundancy-checking   capabilities. 

•  It  contains  security  safeguards  to  control  the  accessi- 
bility to    the    data    elements. 

•  It    has    a  command  language. 

•  It    has   reporting  capabilities,    such    2.s: 

-    predefined     management-oriented,      statistical     or 
summary   reports 

— al-hoc   user -de fined   reports 

-cross-reference   reports 

-elements    usage   reports 

-audit    trail  reports 

-change-effect    reports 

-error    reports 

•  It  has  retrieval  capabilities,  such  as  keywording, 
indexing,    and   orline  queries. 

•  It   has   facilities   for    interacting   with   a   DBMS   [Ref.    5]. 
A    DDS    would    be    useful   tc    SFLICE   as    a    document aticn    tocl. 

Hithin  the  applicaticns  environment,  analysts  and  users  of 
the  EES  would  be  required  tc  define  system  data  definitions 
and  leccrds  as  well  as  other  elements  of  the  dictionary.  In 
the  process,  old  definitions  would  be  updated,  cutdated 
definitions  would  be  discarded  and  new  definitions  would  be 
input.        Redundancy-checking   capabilities      would   prevent   two 
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elamer.ts   frcm  having    different   descriptions.  Use   of    c    CDS 

would  enforce  establishment  of  standard  data  definitions  and 
descriptions  for  these  applications  programs  used  by  the 
SPLICI   system. 

When  the  DDS  has  been  designed  and  is  part  of  the  SPLIC2 
system,  it  could  serve  as  an  important  basis  for  the  future 
development  of      projects   tied      to   UADPS-SP.  By   cataloging 

data  requirements  resulting  from  requirement  analysis  activ- 
ities [Bef.  9],  the  DES  becomes  an  aid  in  the  development  of 
new  programs.  Eventually,  the  DDS  for  SPLICE  could  facili- 
tate conversion  of  the  present  file-oriented  applica-ion 
system  to  a  DBMS-orianted  system  when  the  DBMS  becomes 
available. 

The  key  aspect  cf  a  DBS  is  that  i-  provides  resource 
independence.  Resources  are  protected  from  changes  in  other 
resources.  Modifications  or  changes  may  be  made  within  the 
EDS  and  this  would  net  necessitate  changes  in  the  applica- 
tions prcgrams.  Conversely,  changes  in  the  applications 
programs  would  not  necessitate  modifications  cf  the  DDS  data 
entities.  In  a  distributed  environment,  this  resource  usage 
flexibility  is  particularly  advantageous.  Uniformity  in 
resource  description  standards,  enforced  by  a  SPLICE  DDS, 
would  enable  a  smoother  and  more  convenient  interface  of 
large    application  systems   like   APADE   and   UADPS-SP   (Ref.    7]. 

E.       PJSSIVE    AND    aCTI75    DDS 

DESs  can  be  grouped  according  to  whether  their 
diet icnary/directory  function  is  active  or  passive. 
Further,  DDSs  can  be  subdivided  into  free-standing  (indepen- 
dent) or  dependent  depending  on  their  implementation.  Table 
I        presents  a        schematic  representation        of  this 

classification. 
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TABLE    I 

DDS    Functional  Classifications 


SOFTWARE    TOOL 


oos 


FUNCTION 


ACTIVE 


PASSIVE 


IMPLEMENTATION 


FREE-STANDING 


DEPENDENT 


DEPENDENT 


a  passive  DDS  is  a  software  package  that  dees  r.ot 
require  that  the  processes  or  system  compon=^nts  deper.d  on 
the  DDS  for  their  data.  In  its  simplest  form,  a  passive  DDS 
only  regist«=rs  the  data  elements  for  programs  and  processes 
en  an  after-the-fact  basis  as  a  documentation  facility. 
Passive  EDSs  usually  are  embedded  functions  within  another 
system,  serve  as  the  data  and  file  pra-def inition  mechanism, 
and  are  an  integral  physical  part  of  another  system.  Since 
the  passive  DDSs  are  embedded  within  another  system,  they 
are  necessarily  oriented  towards  the  characteristics  and 
internal   representation   of    that    system. 

An  active  DDS  is  a  separate  and  distinct  software 
package  that  functions  mainly  as  a  tool  for  identifying, 
locating,  controlling,  reporting,  and  manipulating  the 
information  about  data  elements  in  a  database.  It  is  a 
basic  tccl  viithin  the  database  environment  that  can  assist 
the    data   administrator,      the      system   analysis/designer,      and 
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the  programniers  in  raaraging,  planning,  and  evaluaring  zh9. 
collection,  storage,  and  usage  of  the  data  resources.  DDSs 
are  said  to  be  active  with  respect  to  a  program  or  process 
if  and  cnly  if  that  program  cr  process  is  fully  dependent 
upon    the   DDS   for   its    data  [Hef.    5]. 

The  existence  of  active  DDSs  as  separate  entitites 
rather  than  as  a  part  of  another  system  is  a  recen-  innova- 
tion in  the  area  of  data  management.  They  may  be  imple- 
mented in  such  a  way  that  they  require  a  DBMS  to  function 
consistently.  A  further  subdivision  of  DDSs  tends  to  make 
clear  the  inpleraentaticn  of  these  packages.  They  are  free- 
standing (independent)  or  dependent.  A  point  that  needs  to 
be  made  is  that  both  cf  these  divisions  function  principally 
as  DDSs,  and  they  are  different  only  in  their 
implementation. 

The  lajcr  differences  between  an  active  and  a  passive 
EDS    are: 

•  The  active  DDS  is  a  self-contained  system,  whereas  the 
passive  DDS  is  sr.  internal  function  of  another  software 
system . 

•  The  reporting  and  retrieval  capabilities  are  extensive 
fcr   the  active    EDS,    and   modest    for    the    passive. 

•  Active  DDSs  have  more  extensive  security  control  over 
the   data  elements. 

''  •      Free-s-^andin  c 

Free-s*anding  DDSs  are  self-contained,  and  perform 
the  basic  functions  of  controlling  and  managing  the  data 
elements  without  dependence  en  a  DBMS.  However,  they  may 
use  prcgrais  not  specifically  written  for  the  DDSs  in  order 
to  enhance  their  capabilities  and  performance.  A  DDS  that 
is  free-standing  may  support  one  or  more  DBMSs  through  the 
use  cf  interfaces,  achieving  mutual  benefit  from  this  asso- 
ciation.     It  should    be   emDha3i2ed   that    the    free-standing   DDS 
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does  not  depend  on  the  DBMS  -c  function  but  the  use  cf  DE:is 
interfaces  can  provide  the  database  administrator  with  a 
greater  degree  of  control  over  the  DBMS.  It  is  even 
possible  fcr  free-standing  DDSs  to  have  interfaces  tc  mere 
than    cne   EE>:s   siault  aneously .  Free-standing   DDSs    ara    also 

known   as  Generalized   or   Independent    DDSs   [Ref.    5]. 

2.      Cepg^nden  t 

The  dependent  DDSs  are  separate  software  sys*sir,s 
that  are  specifically  tailored  to  a  general  purpose  DBMS. 
They  provide  the  DBWS  with  control  and  management  cf  the 
data  elements  by  supplying  the  DBMS  with  the  descriptions, 
definitions,  locations,  and  cross-references  of  ths  data 
elements.  In  turn,  DBMS  resources  such  as  file  structure 
and  acc=£s  methods  are  made  available  to  the  DDS.  Because 
the  dependent  DDS  is  designed  and  iEplemented  tc  be 
DBMS-specific,  the  portability  of  this  type  cf  DDS  is 
restricted   to   installations    having   that    particular    DBMS. 

C.       SCFTSARE   INTEHFACIS 

The  software  interface  provides  a  formatted  pathway, 
enabling  the  DDS  to  provide  a  set  of  data  attributes  to 
other  software  systems  such  as  compilers  and  Data  Definition 
Languaia  (DDL)  processors  and  enabling  these  systems  to 
retrieve  and  update  information  in  the  DDS  either  statically 
cr   dyramically   [ Ref.    6]. 

The  static  interface  links  the  DDS  with  another  system 
indirectly  via  the  extraction  of  a  file  of  formatted  data. 
For  exaiDple,  the  DBA  enters  into  the  DDS  all  pertinent 
transactions  to  describe  the  database.  After  reviewing  the 
accuracy  of  this  database  description  the  DBA  activates  a 
DDS  ccmmand,  say  GEKZRATE,  that  uses  this  description  to 
provide    a    file   containing   DDL      translates   this   generated   DDL 


18. 


into  a  schema  file  that  the  run-time  unit  of  the  D3MS  can 
access. 

Static  interfaces  differ  depending  upon  wherhar  thev 
interface  the  DDS  with  user-written  programs  or  with 
vendcr-stpplied  software  packages.  Static  interfaces  for 
programs  written  in  languages  such  as  COBOL  and  PL/1  produce 
f ile  /  record,  and  database  descriptions  for  the  user 
programs  from  the  DDS.  These  interfaces  feature  edit  capa- 
tilities,  format  options,  and  various  other  functions  to 
make  the  interface  mere  flexible.  Static  interfaces  for 
software  packages  such  as  DDL  processors,  communication 
monitcrs,  and  guery  processors,  produce  formatred  statements 
for  these  packages  or  create  specially  encoded  control  files 
for    their   use.  The  options    for   customizing     the   interface 

with  these  types  of  software  packages  are  more  limited  than 
are  the  options  provided  for  interface  with  user-written 
programs.  Also,  these  packages  generally  have  more  rigid 
language  formats  and  the  interface  statements  are  usually 
used    only    by  the  DBA    [Bef.    6]- 

Static  interfaces  are  prevalent  because  of  their 
utility,  compatibility  and  efficiency.  The  static  DDS  can  be 
made  compatible  with  many  versions  of  other  software  pack- 
ages (i.e, several  different  CEMS*s)  and  can  be  developed 
independently  of  the  source  code  of  particular  software 
packages.  A  disadvantage  to  the  user  of  a  static  interface 
is  the  extra  effort  that  lay  be  required  t.o  generate  and 
catalog  data  for  the  CDS.  Plus,  the  static  interface  i-^self 
has  no  capability  of  updating  the  data  of  the  system  with 
which  it  interfaces  and  therefore  data  in  other  systems  can 
become    inconsistent    with  data    in   the   DDS. 

Dynanric  interfaces  provide  direct  access  of  the  DDS  to 
ether      software    modules.  This   direct     access   is      commonly 

achieved  by  high-level  interface  commands  that  shield  the 
sof-ware      package    from      the      physical      details  of      the      DDS. 
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Dynamic  int'srfacis  previa^  ccr. sist^r.cy  cc-trol  and  cipahili- 
tias  icr  hoih  uodats  and  ratrirval.  Zha.T.q'hS  10  th-  DDS  -ir~ 
auucrcatically  r^^flectsd  in  -^.h?  nsx',  sxacution  of  any  so  i-- 
war  i  packag-^s  tc  which  tha  DDS  is  in- erf  ac^rd.  A  scf"^v/ar  = 
packaa-:  can  cirecniy  r=tri9VB  and  upcat-5  data  s^or^d  in  -h-3 
DD5.  ?cr  =xainpl=^,  a  COEOL  preprocessor  can  ra-ri=v?  fils 
descripnions  frca  th€  DDS  and  upda-a  -h^  DDS  "o  r?fl5ct  nhe 
E^w  ccmpila-ion  dat?  in  ths  idantif icaticn  of  invoking 
rr? '  •:! ---I.  All  r3.7u=3-s  by  scfnwar^:  packages  for  dana  ar^ 
routed  nhrcugh  the  DDS  by  a  dynamic  interface  func-ion,  so 
th=  s^curi-y  and  validity  ch9cks  of  th^  DDS  ars  always 
applied   [Rsf .    6 ]. 

Us£  of  a  dynamic  interface  incurs  significant  ov=rn€ad 
due  to  th*=  size  and  complex  s-ructur<^  of  th=r  DDS. 
Applica"icn  development  support  aids,  such  as  cr eprccasscrs, 
source  program  manacsrs,  and  design  aids,  asnsrally  can 
afford  "his  overhead  because  r^-sponse  time  is  no-  crinical 
tuT  on  the  other  hand,  efficiency  is  critical  for 
transaction-processing  systems  (i.a.  a  query  processor)  that 
reference  the  DDS.  Tc  reduce  the  pccential  ov^rh^ad,  common 
queries  lay  be  preccnipiled  and  stored  in  n:  -  DDS  or  the 
software  packages  can  retrieve  all  the  data  required  for  a 
transac-ion  at  once  and  therefore  future  acc-sses  for  this 
transacticn   become    memory  lookups. 

r.       CCN?iPT    FQilCTIOSS 

The  integration  of  a  DDS  into  its  environment  is 
provided  ty  convert  functions.  These  functions  alleviate 
some  cf  the  problems  encountered  in  initially  populating  a 
EDS.  The  convert  functions  cf  a  DDS  scan  source  programs, 
database      descriptions,  and      teleprocessing        environment 

descriptions  and  automatically  produce  maintenance  trans- 
acticns.  The    DBA      will      still      have   to      scrutinize      these 
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G.--z^rali2£  i    zz^T.SciCtic^.s      for    t'n^.      possibili-y  cf      rrGur.dcnt 
ar.d    ncr.Htandard    ^n-ri^s.         Ar.    example^    would   b?   if    t':.=,    -rr.ing 

-  '-  ^  •" 


,-.  -^  ■<-  —  --.  "^ 


convr?  nticr.s   ussa   m    scurcs      prcgranis    ar-5    qlcoi. -^  j^j.- c, 

tr.^    LEA    will  fir.  d   it    necessary      to   cha. igf,    d^-ails    in    mar.v   of 

th=-    tra  r.sac  Tion  s  in    crdrr   tc   iroposi    s-.andardization. 

Ccnvsrt    functions   are  off<?.red   to      convert   data    froT.    both 
liSar-writt  en  prcarams   and    from   a    DBMS    and    its   r-lat=d    ccucc- 


lurnion -~s    ccnv=rsion 


n-.n-.s.  This  is  shown  in  a  CDS  -hat 
facilities  for  several  pr ocramming  languac3s  (i.^,,CC3CL, 
rL/1,  assemblar),  as  will  as  for  th=  DDL  procasscr  ani 
r^rport  writ-r  of  a  aiven  D3M3.  Convart  functions  hav?  four 
significan 

transactions,  2)  th?  input  file,  3)  the  ccirinand  options,  ani 
U)  -^he  sourca  prograrn  analysis.  The  data  dictionary  rr.ainta- 
nancr  transactions  that  are  created  by  convert  functions 
usually  also  contain  th3  relationships  between  data  entities 
(i.e.,  hetween  a  record  and  an  element)  and  most  language 
clauses.  For  example,  elem'^-nt  transactions  generated  by  a 
C030L  convert  function  capture  data  for  the  DDS  from  the 
program's  OCCJRS,  PICTURE,  and  USA3Z  clauses.  A  convert 
function  is  considered  to  be  equivalent  if  the  DDS  can 
rsgsnerate    the      input   source   data      description   from      the    DDS 


c- rr-^  -  *i-5r.-    characteristics;     1)    the    content   c"^   th«    generated 


data. 


The   ability      to   analyze   the 


r^?;*?> 


or    source    programs 


can    make   th«^      DDS   a    valuable   tool    for      auditing    adherence  tc 
scf-^ware      control      techniques.  The      DDS      can      detect      ani 

disclose  inconsistencies  in  the  names,  formats  and  clauses 
{comments,  initial  values)  cf  the  record  definitions  used  in 
several  programs  and  the  corresponding  standard  record 
definitions   in    the    DES  [  Bef .   6]. 

2-       IJI?iaCNISENT&L    DEFZSDESCI 

The   environmental  dependency   characteristic      cf   a   DDS   is 
detBrnined        by     its        reliance      on        a      specific         hardware 
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conf  iguraticn,  an  operating  sY5?-3m,  a  DBliS  or  a  -=irpro- 
c==^sing  mcnitor.  The  DDS  should  bs  abl?  to  op^ra--  ir.  all 
'=nvircnr[i'=r.ts  with  riC.loss  of  ^ffici^ncy  and  f un£;nionality 
cut    at   ths    prssen-    tinse   this    is    not   attainable  [H^f.    6], 

Tha  amount  oi  environnental  dspend^ncy  b^tv9sn  a  DD3  and 
a  DB.'.'S  is  dsterminad  by  the  dsgree  to  which  th=  DDS  r-^li^s 
c:.  th~  DE-MS  for  data  mar.ag'=3iiicnt  ssrvicss  and  th^^  scurca  of 
data  used  by  the  D3?!S  for  access  to  stor'?:d  databases.  Tha- 
t^cz--  cf  invironmental  depf=ndsncy  is  crck  =  n  into 
INDZPSNDZ:JT,    DSMS-APPIICATION,     and    EMBEDDED    a?proach<^3. 

In  th€  INDEPZNDSKT  approach,  ths  DDS  is  autcncsous.  Th^ 
DBMS  maintains  its  own  sourcs  of  data  and  the  DDS  usss  ncna 
cf  the  EE?^S  utilitias  for  providing  data  dictionary  manags- 
iisnt  functions.  The  benefits  of  this  approach  are  that  it 
nialcas  the  dictionary  niore  portable  and  will  probably  bs 
possible  to  us ^  the  dictionary  on  a  variety  of  hardware  and 
cperatinc   system   configurations. 

In  the  DBMS- APPLICATION  approach,  the  DDS  appears  to  the 
EB:is    as    just   another    database.  The    DBMS    maintains   its   own 

data  for  each  database  and  these  are  seoarat s  from  the  DDS. 
The  DEXS  utilities  provide  lost  of  the  DDS  manageaent  func- 
tions, but  data  is  defined  separately  for  the  DB.'IS  and  for 
the  DDS.  The  DDS  will  interface  dynamically  with  only  one 
E3MS  and  i-s  related  components,  but  there  can  be  static 
interfaces  to  other  DBMSs  that  operate  with  the  same 
hardware. 

In  the  EMBEDDED  approach,  the  DDS  is  actually  a  compo- 
nent of  -^he  DB^IS.  This  approach  provides  complete  integra- 
tion of  the  DDS.  The  DBMS  utilitiis  provide  the  DDS 
management  facilities  and  the  DBMS  uses  the  DDS  to  direct 
access  to  stored  databases.  No  other  internal  directories 
exist  for  the  DBMS,  and  its  related  components  rely 
completely  on  the  DDS  for  data.  For  example  a  query 
processor      extracts    user      views   from      the    DDS 
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applies   integrity     ccr.straints    specifiad      in   the      DDS    fc^fcr'? 
s-oring    a    data    element. 

The  EBA  needs  to  decide  what  functions  this  powerful 
tool  in  a  database  srvironment  is  to  perform.  The  DBA  will 
have  to  evaluate  the  pros  and  cons  of  each  function  that  has 
been  discussed  and  then  weigh  them  according  to  th^  ralativ? 
importance  of  each  function  to  the  DBA's  environment.  For 
example,  dees  he  want  the  software  interfaces  to  link  to 
cthei  systeirs  statically  or  dynamically,  how  much  do=3  he 
want  the  convert  functions  to  do  automatically,  whai  pric«? 
is  he  willing  to  pay  for  this  service,  and  what  reliance 
does  he  want  the  DDS  to  have  on  the  hardware  configuration, 
an  operating  system,  a  DBMS,  or  a  teleprocessing  monitor? 
Cnce  ttese  questions  are  answered  the  DBA  must  be  sure  that 
the  functional  requirements  of  his  environment  have  been 
met. 

F.       CCNTENTS    AND   LOGICAL   STBDCTORE   OF    DDS 

A  useful  DDS  will  contain  more  than  merely  information 
about  data.  It  is  desirable  that  the  DDS  represents  such 
system  resources  as  cata,  hardware,  software,  transactions, 
personnel,  and  documents.  Entities,  attributes,  and  rela- 
tionships associated  with  these  resources  are  pres?=nted 
below . 

Eata  resource  information  should  include  the  following 
entities:  data  elem.ents,  data  groups,  schemas/subschemas, 
records,  files,  and  databases.  Attributes  for  these  enti- 
ties must  be  determined  by  the  anticipated  usage  of  the  DDS. 
[Hef.  6]  suggests  typical  attributes  for  the  data  element 
entity  and  these  appear  in  Table  II.  These  attributes  have 
been  chosen  from  existing  commercial  data  dictionary/ 
directory  systems.  Attributes  for  the  file  entity  have  been 
suggested  in  the  SPLICE  specifications  [Ref.  10],  and  appear 
in   Table    III. 
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TABLE    II 
Data   Elament    Attributes    (from   Allen   et   al    1982) 


Type 
I^ciige 

Unit    of   Measure 
Usage 


Lanauaas    names 

Repetitions 

88   Levels 

Key 

Default    value 

Display   format 


1                           TABLE  III 
1 

— \ 

1                  File  Entity  Attributes 

rile  name             Format  (sea,  random,  bin) 

locations             Access  control 

Size  (in  bytes)       Access  security  Dro-tec^.ion 

Relationships  are  associations  between  one  or  more  data 
entities  and  are  also  a  function  of  anticipated  usage. 
Figure  2.1  is  a  possible  network  structure  relating  data 
entities.  This  structure,  implemented  in  the  appropriate 
EEMS  would  provide  answers  tc  the  following  gueries  via 
conventional  query   languages   and   processors: 

•  "List    the      record   layout    (all     data    elements      and    kpys) 
for   the   Master    Stock  Item    Reference    (MSIR)?" 

•  "What        locations  in        the        network  stock        item 
5SC5-00-255-369S,    resistor,    fixed,    composition?" 

•  "What      files      and     records      contain      the      data      element 
NATIONAL- STOCK- NUMBER?" 

•  "Who   is  the    manufacturer    of    part-number    2i;3W-24-A?" 


2a 


1. 


SCHEMA       1 
— . ■«- 
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!  VALUE       I 


Figure   2. 1        Logical   Structure    Describing  Data    Resources 
(from    Schnisdewind   and    Dolk    1983). 


Hardware  entities  and  attributes  identified  in  [Ref.  10] 
have  keen  specified  as  part  of  the  Configuration  Management 
Systeir  (CMS)  for  SEIICE,  A  selective  sample  is  shovn  in 
Table    IV,  The  DOS      could    be      of    value      regarding    hardware 

resources   if  it    could     display  topological   information    about 
all    or   part     of   the    SPLICE    network.  One    logical    structure 

which    might     provide    this      capability    within      a    conventional 
CBMS    ervironment   is    civen   in   in   Figure    2.2   [Ref.    7]. 
Possible  queries   might   include: 

•  "How   many   terminals   are   located   within   each   LAN?" 

•  "Which  LANs   have   database    processors?" 
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TABLE    IV 

Selected  Hardware    Entities   and   At-tributes 


Entiti<=s 

Frccessing  system 
Secondary  storage 
Ccnunimications   system 

Attributes 
Type 
Kg  del 

Plodel   number 
Serial    number 
Mf qer'  s    number 
Source 


Concentrators 

Terminals 

LAN   I/O    peripherals 

Features 

Description 

Docu.    references 

Usage    by   site 

Cost 

Maintenance   activity 


Reccitmended  software  entities  and  a-tributes  from 
[Ref.  10]  are  summarized  in  Table  V.  One  possible  logical 
structure  for  software,  transaction,  and  report  entities  is 
given  in  Figure  2.3.  The  advantage  of  this  kind  of  struc- 
ture is  that  one  can  extract  data  flow  information  irrm  it 
relatively  easily.  Thus  a  query  to  th3  effect  of  "construct 
a  data  flow  analysis  (input  files,  mod ules/transacticns, 
output  files,  reports)  for  the  APADE  system"  should  be 
reasonable  to  i nplement.  Inclusion  of  these  resources  in 
the  DDS  contributes  greatly  to  the  viability  of  the  DDS  as  a 
systeiEs   analysis   and    design    tool. 

The  EDS  can  catalog  documents  other  than  reports.  A 
summary  of  entities  and  attributes  for  various  kinds  of 
documents   is  shown    in  Table    VI   [Ref.    10]. 

Personnel  is  another  resource  which  can  be  represented 
in  a  CDS.  Information  about  users,  account  numbers,  and 
access  authority  may  have  important  impacts  on  security 
considerations.  DBAs  could  find  it  useful  to  have  access  to 
data  about  programmers,  analysts,  and  the  programs/systems 
which   ttey    are   responsible    for.      Because   of   the   diversity   of 
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Figure    2.2        Logical  Structure   of    Hardware  Resources 
(frca   Allen   et   al    1982). 


possible  relationships  between  users  and  other  resources  in 
the  DDS,  no  structural  representation  will  be  addressed.  As 
with  the  other  resources  discussed,  the  applicable 
lelaticnships  will  be  a  functicn  of  the  intend-^^d  usage  of 
the    DDS. 

G.       IHPACT    CF    A    DDS 

It  has  been  stated  in  the  introduction  that  there  is 
increasing  awareness  of  the  importance  of  data  as  an 
orgarizaticn   resource  and   a  recognition   that   it  must  be 
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Entities 

Operating    svstam 

Cperational   suoDcrt   s 

:yst 
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Environmental  sjst^w 
Application   software 

Attributes 

Program-  id 

Date    relsas^^d 

Revision    number 

Product,    number 

Revision    date 

Source 

Date    comoiled 

Fea'^ures 

Tyoe    of    ccrciler 

Document  ation 

Patch   level 

Usaqs 

Change    level 

Cost 

License 

Maintenance    activ; 
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Figme  2.3   Logical  Structure  for  Software,  Transactions, 

and  Report  Resources. 


controlled  as  carefully  as  other  major  resources  within  the 
organization.  When  management  has  gained  control  of  the 
data  resource  by  recording  all  information  about  it,  it  can 
then  begin  to  impose  controls  over  the  availability  of  the 
resource  and  to  develop  standards  for  its  use.  In  this  way 
the  data  resource  can  be  managed  to  the   best  advantage  for 
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TIBLE    VI 
Docunent/Report    Attributes 


Name  Source 

Numter  Feature 

Product    number  Descrintio 

Release    date  Quantity 

Revision    number  Cost 


the  existing  information  systerr  and  can  be  effectively  rede- 
ployed to  ireet  changirg  information  requirements.  To  obtain 
this  control  of  the  system  resources,  a  DDS  was  described  as 
teinc  the  software  tool  that  will  help  to  insure  the  best 
cse    cf    the    system   resources. 

In  -^he  process  of  gaining  ccntrol  of  the  resource,  indi- 
viduals vill  los<=  the  freedom  to  define  and  use  resources  in 
their  own  way  to  satisfy  their  needs  alone.  In  return  for 
this  loss  of  freedom,  the  user  will  have  access  to  accurate 
inforiration  about  the  definitions  and  usage  of  all  the  data 
contained    in  the  system. 

A  DDS  improves  a  Database  Administrator's  control  over 
the  design  and  the  use  of  the  database.  A  DDS  enables  him 
to  ccnticl  and  document  the  formulation,  meaning,  and  usage 
cf  data  structures.  It  enables  him  to  evaluate  existing 
data  redundancy,  provide  accurate  data  definitions  for 
inclusion  in  prcgrairs,  and  it  enables  him  to  insure  that 
nianagemer.t '  s  requirements  for  data  standards  are  obeyed. 
The  most  important  benefits  are  that  the  DBA  will  be  abls  to 
assess  quickly  the  impact  of  any  proposed  change  to  comironly 
used  data  and  to  estimate  the  likely  cost  and  time-scale  of 
any    such  change.  During    this   changeover,      the      DBA   can    be 

assured  cf  completeness  (because  the  DDS  will  show  all  the 
programs,  files  and  reports  affected)  and  accuracy  (because 
the    CES    can   generate   new  coding  to   reflect   the  change) . 
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Th€  systems  designer  will  be  able  to  usa  th^  DES  as  a 
.central  source  of  information.  It  will  allow  hiir.  to  sake 
use  of  data  that  is  already  available  and  help  him  to  avoid 
duplicating  data  definitions,  thereby  preventing  redundancy 
and  inconsistency.  The  DDS  can  generate  data  files  to  be 
used  for  system  testing,  enable  him  to  check  the  conten-^s  of 
data  files  produced  curing  systems  testing,  and  provide  the 
designer   with   documentation    of   the   system. 

Application  programming  management  will  be  able  to 
enforce  data  definition  standards  by  insisting  that  all  data 
definition    coding   is      produced   by   the    DDS.  This    will  also 

lake  it  easier  to  control  the  implementa-^  ion  of  design 
changes  thai  arise  during  development.  For  the  application 
progiammers  themselves,  much  of  the  tedium  of  writing  large 
amounts  cf  coding  will  be  removed.  As  the  DDS  becomes  more 
involved,  greater  amounts  of  coding  will  be  generated  by  the 
EDS  itself.  Further,  assistance  with  -he  gen-ration  of  tes- 
data  and  the  checking  of  results  by  the  DDS  will  reduce 
application  development  time  and  improve  the  accuracy  of  the 
finished    programs.  Once    management      has    used      the   DDS     to 

assess  tl-e  impact  of  a  proposed  change,  the  task  of  amending 
the  applications  can  proceed  with  increased  confidence.  The 
EDS's  cross-referencing  will  show  the  maintenance  programmer 
preciselj  what  programs  will  be  affected  by  a  particular 
change.  As  programs  are  constantly  amended,  the  DDS  can  be 
used  to  record  the  changes  ensuring  programming  management 
control  cf  the  progress  and  completeness  of  the  change.  A 
big  impact  that  the  EDS  has  en  the  current  system  is  tha-^ 
before  allowing  ths  changed  programs  to  replace  the 
prodtcticn  versions,  the  DDS  can  be  used  to  generate  test 
data    and   check   results. 

Ihe  operations  department  will  be  impacted  since  it  will 
be  able  to  maintain  tie  privacy  of  data  by  reference  to  the 
DDS    tc   check   who    is    allowed    to   use   what    data.         The    DDS    will 


30 


aid  the  department  in  ths  creation  of  job  control  lanquag'r 
parameters,  control  of  different  versions  of  prcgrani 
librari3s  and  data  files,  distribution  of  multiple  copies  of 
output,    and    disccvering   the    source    of    invalid   data. 

In  summary,  it  becomes  apparent  that  the  introduction  of 
a  DDS  will  have  an  effect  at  many  levels  in  an  organization. 
It  will  create  new  tasks,  but  in  return  will  reduce  the 
effort  reguired  by  si:ch  activities  as  documentation,  ceding 
of  programs,  creation  of  test  data  files,  checking  and 
auditing  of  output  files.  The  DDS  will  enable  management  to 
control  cata  processing  at  all  levels  and  will  provide  an 
effective  means  of  communicating  data  processing  require- 
ments between  user  departments,  operations  departments,  and 
the  ADP  department.  System  resources  will  be  recognized  as 
immensely  iirportant  corporate  resources  and  will  be  managed 
and    ccnticlled    accordingly. 
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III.     TMEEM    DDL    DATA    CICTIONABY    AND    DISTRIBOTION    STRATEGIES 

I.       DICTIONARY 

Th€  need  to  manac€  data  resources  raqiiir'=s  systens  tha-^ 
identify,  d<;scribe,  define,  and  relate  the  basic  unit  of 
infcrmation,  the  da-ta  element.  The  TANDEM  C-rr.puter  Cctr.pany 
offers  a  Distributed  Database  Management  System  (DDBMS) 
called  ENCOMPASS  that  handles  this  need.  ENCOMPASS  consists 
cf  standard  software  products:  DATA  DEFINITION  LANGUAGE, 
ENFOEM         QUERY  L ANGUAGE/REFCET  FORMATTER,  TRANSACTION 

MONITORING  FACILITY,  PATHWAY  TRANSACTION  PROCESSING  SYSTEM, 
and       ENAELE    SCREEN       CCECL       GENEEATOR    [Ref.     11,12,13].  The 

ccmbicaticn  of  these  software  tools  works  with  the  TANDEM 
NONSTCP  systems  to  prcvide  a  reliable  and  high  performance 
system  that  is  capable  of  accommodating  peak  workloads, 
hardware  expansion,  database  modifications,  and  application 
growth. 

The  Data  Definition  language  (DDL)  is  a  language 
processor  that  enables  the  user  to  design  and  create  a  data 
dicticnaiy.  This  creation  takes  place  through  a  combination 
cf  statements  and  ccmmands  that  can  be  used  both  interac- 
tively and  in  batch  mode.  By  using  the  DDL  statements,  the 
user  can  define  or  icdify  the  structure  of  the  database, 
generate  file  utility  statements  to  create  database  files, 
and  provide  source  language  data  definitions  output  for 
COBOL,         FOPTRAN,         and      TA I      compiliers      [Ref.     13].  This 

interaction    is    illustrated    in   figure    3.1. 

The  actual  DDL  looks  like  COBOL  and  provides  two  types 
cf  statements:  DEFIMTION  statements  and  RECORD  statements. 
The  DEFINITION  statement  is  a  data  description  independent 
cf   any   record   that    specifies   fields   and   groups.         The    RECORD 
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Figure    3.1        Interaction  of   the   DDL. 

statercent  defines  record  structure  and  file  attributes,  and 
can  refer  tc  a  DEFINITION.  When  this  happens  the  groups  and 
fields  or  the  DEFINITION  are  inserted  into  the  RECORD  state- 
ment at  the  point  where  the  DEFINITION  name  is  written. 
Many  BICCRD  statements  can  share  the  data  structure  cf  the 
same    DEFINITION.      This  application      of    DEFINITION    statements 
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makes  it  -sasy  tc  standardize  a  data  structure  thrcughcut  a 
large    catafcase.  This   insures   consistency      of    ncins^nclat ure 

and  data  tjpes  among  different  records,  files,  and  progran.s. 
The  EEL  will  take  every  DEFINITION  and  HECOED  3tatsm3nt  in 
the  EEL  input  file,  plus  user  ccnaents,  and  catalog  thera  tc 
form  a  data  dictionary.  The  data  dictionary  will  te  a 
complete,  centralized  description  of  the  data  structures, 
records,   and  files    that   make   up   the   database. 

This  data  dicticnary  will  essentially  be  a  database 
about    the      system   databases.  It    will      provide    a      powerful 

development  tool,  a  central  scurce  for  data  definitions,  and 
complete      database      documentation.  There        are      +wo      main 

functions  of  the  data  dicticnary  in  the  realm  of  the 
ENCOMPASS  DDBMS.  First,  the  DDL  data  dictionary  will 
provide  a  database  cf  what  kinds  of  information  are  rriain- 
tained,  such  as  stock  numbers,  document  numbers,  or  routing 
identifiers.  Secondly,  it  supports  ENFORM  by  providing 
"mapping"  information  to  describe  the  file  type  and  access 
information  of  the  database.  The  query  processor  cf  ENFCEM 
Ms^s  this  mapping  information  to  determine  the  most 
efficient    way  to   access   the    database. 

A  feature  of  the  data  dictionary,  once  it  has  been 
compiled  by  the  DDL,  is  that  it  becomes  a  single  scurce  for 
all  data  definitions  in  the  database.  This  means  that  every 
program  that  accesses  a  database  can  use  data  declaration 
source  generated  from  the  dictionary.  Therefore,  the  EBA 
can  exercise  control  over  the  structure  of  the  database. 
The  data  dictionary  also  stores  information  in  a  form  acces- 
sible to  the  ENFCRM  CDZRY/REFOBT  WRITER,  so  users  can  easily 
prepare  ad  hoc  dicticnary  reports.  One  of  the  best  features 
cf  the  TANDEM  data  dictionary  is  that  separate  data  dicticn- 
aries  can  te  stcred  en  separate  disk  volumes  for  different 
databases.  This        feature      allows      concurrent        users     of 

different      dictionaries     to      perform      database      interactions 
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without  access  conflicts  that  can  cause  bo'rtl  an'rcl'*:- 
[Ref.    13]. 

since  v^  now  knew  what  the  data  dictionary  wi-hir.  th? 
ENCOMTASS  DEBas  is  made  up  of,  what  it  provides,  wha-  it 
produces,  and  what  its  features  are,  we  must  new  ask  the 
question  what  can  this  data  dictionary  do  for  SPLICE?  Ths 
make-up  of  the  TANDEJI  dictionary  will  be  evaluated  according 
to   the    tasic  profile    given    in    the   earlier   part  of    this    work. 

E.       DATA    EICTI0NA3Y    CCflPARISOMS 

The  following  ccirpariscn  of  rhe  below  described  data 
dictionaries  is  intended  to  give  a  rough  evaluation  of  the 
TANDEM  product  relative  to  what  is  currently  available  from 
ether    vendors.  In    no     way  are      we   endorsing      a    particular 

product.  The  intent  of  this  limited  survey  is  to  lock  at 
select^a  features  offered  by  the  different  software  packages 
and  note  how  -he  four  products  compare  without  making  quan- 
tifiatl?  judgements  whether  one  or  another  is  good,  bad, 
superior      or   inferior.  The      informa-ion      provided    in      the 

following  tables  was  derived  from  [Ref.  5,6,11,12,13,14]. 
The  section  bagins  with  a  brief  general  description  of  each 
of   the    four   data    dictionary    packages   considered. 

"••      L^ls.  Control    System     (DCS) 

The  Data  Control  System  (DCS)  is  a  dictionary  system 
produced  and  developed  by  Cincom  Systems  Inc.  The  system  is 
implemented  as  an  application  program  that  requires  Cincom's 
DBMS    which    is  called    TOTAL.  DCS    was    previously    referred  to 

as   -he   Cincom   Data    Dictionary. 

2  -      Datamanaqer 

Datamanager  is  a  free-standing  data  dictionary 
system      that        is      developed      and        marketed      by         KSF      Inc. 
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Eatair.anager  is  the  r.ucleus  cf  a  faaily  of  products.  I- 
contair.s  the  facilities  for  creating  and  maintaining 
dictionaries  used  in  a  traditional  file  environnent. 
Datamanager  also  has  dictionary  query  facilities  as  veil  as 
a  report  generator.  Datamanager  is  not  tied  to  a  particular 
IBMS  end  is  capable  cf  interfacing  to  IDMS,  ADBAS,  I^.S, 
TOTAL    and    SYSTEM   2000. 

3.      k^lLQ  Data   Dictiona  ry 

There  are  two  versions  of  the  DB/DC  Data  Dictionary 
which  is  a  product  of  International  Business  [Machines  (IBM) 
Corporation.  One  version  is  for  operation  under  OS/VS  and 
the  ether  is  for  operation  under  DOS/VS.  The  DB/DC  Data 
Dictionary  is  a  DEKS-applicaticn  program  with  several 
management  features  which  have  evolved  since  the  product  was 
first    released    in   197a. 

4  .      DDL   Data   Dictionary 

The   Data   Description   Language    (DDL)       Data    Dictionary 
produced        by        TANDZK        Software      Products        Inc.  is        a 

EEMS-application  approach  that  requires  the  TANDEM  DBMS 
called    EKCCHPASS.  The   TANDEM      format    for      dictionary    file 

entries  was  used  in  the  preliminary  DDS  design  proposed  in 
this    thesis. 
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C.       AN    13P1AINATI0N    CF    THE    lEBMS    DSED    IN    THE    SURVEY 

SOFTWARE  PACKAGE  NAME:  Nam «  or  acronym  by  which  th€  D/D  is 
known. 

VENDOR:    Name  of    the    company    that    markats    ":he    product. 

OPERATIONAL  MODE:  Mcc6  in  which  the  D/D  opera^ss,  fcatch  or 
online. 

CSS    OF    A    DATABASE    MAlsAGEMENT    SYSTEM     (DBMS):       Note    infer€ncss 
to,    cr   requirements    for,    a    DBMS- 
ONLINE   QUERIES?:    Does   the   D/D   have   online    query    capability? 

ONLINE  CUEEY  LANGUAGE?:  Does  the  query  language  require 
fixed-form    cr    free-fcrm    queries? 

SYNONIM?:  Can  a  synonym  (word  or  abbreviation)  be  used  as  a 
substitute    for    the   data   element   identifier? 

KEYWORD  CAPABILITY?:  Can  an  element  be  identified  as  a 
keywcrd? 

DATA  SIRDCTURE:  What  data  structure  is  supported  by  the  D/D, 
network,    hierarchical,    cr  relational? 

VALIEATICN:  Is  data  validation  performed  by  the  D/D  cr  by 
seme    ether    means? 

EEDUNIANCY/r^CONSISTENCY  CHECK?:  Is  there  a  specific  feature 
that  identifies  whether  the  data  element  is  redundant  or 
inconsistent? 

DEFINITICN/DESCHI?TIC^?:  Is  there  a  facility  for  defining 
and/or    describing  a    data   element    in   narrative   form? 

RELATIONSHIPS?:  Is  there  a  capacity  for  specifying  the  rela- 
tionship of  a  data  element  to  another  data  element  or  to  a 
higher   level   structure? 


39 


CWNEE/DSEH?:      Is   thers    a      facility    for    indicating    authorized 
users    (persons    or   programs)     or   owners   of   data   <5l9ments? 

AD   HOC:    Can   the    user   structure   his   own    reports,    on    an   ad   hoc 
basis? 

D.       ACTIVE    OR    PASSIVE 

The  lANEEM  data  dictionary  function  within  th€  SPLICli: 
project  would  have  to  be  categorized  as  an  acti  ve/aependsn*^. 
DDS.  The  reason  for  this  classif ica-ion  is  that  the  soft- 
ware package  does  require  the  Navy  Supply  System  components 
to  depend  on  the  DCS  for  their  data,  and  is  a  software 
package  tha-  functions  mainly  as  a  tool  for  manipulating 
information  about  data  elements  in  a  database.  The  depen- 
dent classification  is  attached  since  this  software  tool  is 
specifically  tailored  to  the  ENCOMPASS  DDBMS.  In  this 
format  the  DDS  will  provide  the  DBMS  with  control  and 
management  of  the  cata  elements  and  in  return  the  DEMS 
resources,  such  as  file  structure  and  access  methods,  will 
be  made  available  to  the  DDS.  Since  the  DDS  is  designed  and 
implemented  within  a  specific  DBMS  environment  i-s  port- 
ability will  be  restricted  to  installations  having  this 
EBMS. 

I.       SCFTSASE   INTERFACES 

The  software  interface  provided  in  the  ENCOMPASS  EDE^.S 
is  a  static  interface  that  links  the  data  dictionary  with 
ether  systems  indirectly  via  the  extraction  of  a  file  of 
formatted  data.  The  dictionary  contains  the  description  of 
the  records  within  each  file  and  identifies  primary  and 
alternate      keys.  The     relational        QDERY/BEPOET      writing 

language    ENEORM    uses      these    as    a    template      for  accessing   the 
records.         This    accessed  infcrmation      will    provide    "mapping" 
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informaticr.  to  descrite  the  file  typ^s  and  to  describ?  th'? 
databas*?.  The  query  processor  of  ENFORM  then  uses  -his 
infoncaticn  to  determine  the  irost  efficient  way  to  ^.cc^ss 
the  database.  3y  supplying  the  software  package  to  ir.tar- 
face  with  -^he  data  dictionary  the  user  has  acquired  edit 
capabilities,  format  cptio.ns,  and  various  other  functions  to 
make    the    interface   acre    flexible. 

The  drawbacks  in  having  static  interfaces  and  using 
vendcr-srpplied  software  packages  compared  to  zY.^  cp-icn  of 
using  dynamic  interfaces  come  in  several  areas.  Changes  to 
the  data  in  the  data  dictionary  will  not  cean  that  the  data 
of  the  sjstem  with  which  it  interfaces  will  be  autoina-*:ically 
updated  and  therefore  data  in  other  systems  can  bfccme 
inconsistent  with  data  in  the  data  dictionary.  Sof-^ware 
packages  cannot  directly  retrieve  and  update  data  stored  in 
the  data  dictionary  nor  are  all  requests  by  these  packages 
routed  thrcugh  the  data  dictionary  so  that  security  and 
validity  checks  of  the  data  dictionary  can  be  applied.  The 
use  of  static  interfaces  is  prevalent  in  the  world  of 
dictionaries  because  of  their  utility  compatibility,  effi- 
ciency, and  small  overhead.  Since  SPLICE  is  largely 
concerned  with  efficiency  in  performing  transaction- 
processing,  this  static  interface  approach  will  be  a  plus 
for   the    project, 

I.       CCN7IET    FDNCTIOSS 

The  convert  functions  offered  by  the  TANDEM  software 
packages  do  not  completely  match  the  definition  given  by 
(Hef.  6].  Convert  functions  are  described  first  as  being 
able  to  scan  source  programs,  database  descriptions,  and 
teleprocessing  environment  descriptions  and  automatically 
produce  maintenance  transactions  that  will  spare  the  DBA 
many      hours     of      manual     effort.  Secondly,        the      convert 
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functions  ars  offered  to  convert  data  from  both  user-writ  tan 
programs  and  from  a  DBMS  and  its  related  compon-v-n-s.  Th  = 
lANDEM  DDL  does  not  perform  the  first  task  but  in  the  area 
of  the  second  function  it  does  operate  very  strongly  as  a 
conversion  facility  for  programming  languages  CCBCLr 
FORTFAN,  and  TAl,  as  well  as  for  the  DDL  compiler  anc  the 
report  writer  of  ENFCBM.  The  DDL  compiler,  once  it  has  been 
given  a  list  of  DDL  statements,  can  produce  the  following 
files : 

•  a    data    dictionary 

•  a    file   utility    program    for   file   creation   command   source 

•  a   data    declaration   source   for    COBOL,    FORTRAN,    TAL 

•  a   schema   report   summarizing    each    record's  structure   and 
each   file's   access   keys 

The  INSCRIBE  fil€  utility  program  (FUP)  commands  will  be 
used  to  create  the  actual  database  files  with  the  specified 
attributes.  The  data  declaration  source  generated  by  the 
DDL  is  available  either  when  the  schema  is  firs*-,  compiled  or 
by  accessing  the  data  dictionary  at  any  other  time.  The  DDL 
will  also  provide  edit  checking  for  all  three  source 
outputs.  For  example,  if  the  user  programmer  asks  for  COBOL 
source  output,  the  DDL  checks  to  make  sure  that  the  schema 
includes  no  COBOL  reserved  words,  and  will  report  what  items 
are    unsuitable    for   the   selected   language.      [Ref.     13]. 

The  question  is  what  does  all  this  mean  for  SPLICE?  By 
gathering  all  of  the  various  database  definitions  and  data 
structure  declaratior  functicns  into  a  single  language,  the 
DBA  gains  control  over  the  database  design  and  implementa- 
tion. It  also  gives  the  DBA  a  data  dictionary  that  docu- 
icents  the  database,  and  can  be  used  in  the  ongoing  process 
of  database  management.  With  the  data  dictionary  being  able 
to  regenerate  the  input  source  data  description  from  the 
dictionary  data,  a  valuable  tool  for  auditing  adherence  to 
software   control   technigues    is   gained.         This    means    the    data 
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dicticnary  within  ths  SPLICE  environment  will  be  afcls  zc 
detect  and  disclose  inconsistencies  in  the  names,  formats, 
and  clauses  of  the  record  definitions  used  in  ssveral 
programs  and  ths  corresponding  standard  RECORD  definitions 
in   the    data    dictionary  [Sef.   6  ]- 

G.       2NVIPCNaE!ITAL   DEIEHDENCY 

There  are  three  levels  cf  environmental  dependency 
between  a  data  dicticnary  and  a  OEMS:  independent, 
EB.IS-applic  ction ,      and   embedded.  The    environmental    depen- 

dency characteristic  cf  a  data  dictionary  is  determined  by 
the  degree  which  a  data  dictionary  relies  on  the  DB:is  for 
data  managei.ent  services  and  the  source  cf  data  used  by  the 
DBMS    for   access    -^o    stored   databases   [Ref.    6]. 

The  data  dictionary  within  the  TANDEK  schema  would  be 
classified  as  having  DBMS-application  characteristics.  This 
allows  randcm  processing,  on-line  updates,  query  processors, 
and        report      generators        to      be        more      efficient.  The 

DBMS-application  methcd  used  by  TANDEM  means  that  "ad  hoc" 
queries  and  special  reports  can  be  processed  quickly  and 
that  data  redundancy  can  be  avoided.  It  also  means  that 
dicticnary  data  descriptions  can  be  used  directly  by  the 
EBMS  rather  than  having  the  dictionary  generate  DBMS  data 
descripticns-  The  test  advantage  of  the  DBMS-applicat  icn 
approach  is  that  a  customized  data  dictionary  can  be 
designed  and  implemented  which  meets  the  special  needs  of 
the  SELICE  informaticn  resource  environment  [Ref.  7].  The 
drawbacks  cf  this  technique  are  that  1)  ±z  makes  the 
dicticnary  less  portable  since  it  is  tied  to  a  specific  DBMS 
and  2)  it  fcrces  the  user  to  buy  and  support  this  particular 
DBMS  software.  Applying  this  to  the  SPLICE  project,  these 
drawbacks  are  negligible  since  the  project  will  be  using  the 
ENCOMPASS    DEMS    provided    by    TANDEM. 
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H.       BISTEIEOTION   CONSIDERATIONS    FOR    TH2    DATA    DICTIOHARY 

In  s  distribuxed  database  environment  there  ars  a  number 
cf  options  for  distribution  of  the  data  dictionary.  Within 
the  SPLIC2  system  every  Ian  will  have  a  database  managsment 
module  for  centralized  control  over  the  data.  There  are  no 
distribution  of  databases  within  a  Ian  [Ref.  4],  The  data 
dicticnaiy  in  the  distributed  environment  itself  becomes  a 
distributed  database.  Databases  may  be  distributed  ever  the 
entire  SPLICE  network  and  the  database  functions  are 
centrali2ed  within  each  Ian.  The  goal  here  is  tc  satisfy 
control    and   integrity  of  the   data   within   -che    network. 

I.       EATA    CISTHIBUTIQS    STRATEGIES 

The  system  architecture  and  the  network  database  raanage- 
ment  system  software  determine  the  distr ibu-^ion  strategies 
which  may  be  considered.  There  are  four  types  of  distribu- 
tion   strategies    for    consideration. 

1.  Centralized-a  single  copy  of  the  database  is  located 
at   one    nod e . 

2.  ?artitioned-a  single  copy  of  the  database  is 
ccmpiised  of  disjoint  subsets  or  partitions  located  at 
various  nodes. 

3.  Replica  ted- there  are  multiple  copies  of  the  database 
with    each   node    having  a    ccirplete    copy. 

U.      Hybrid-there   are      multiple   copies   cf   subsets  of   the 

database      where      each      node      may    have      as      many  of      the 

partitions   of   the  database   as  necessary. 

There    are   different   advantages   and    disadvantages  to   each 

cf  the  four  distribution  strategies  mentioned.  The  primary 
consideraticns    for    discussion   are   reliability,   data    storage, 

retrieval      and    update     response      times      and  various  control 
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mschaFiisis   and    tradeoffs   in    either   software   or   ccmmunicct ion 
cos-s, 

1 ,      Cer.  trali  zsd 

Th€  centralized  database  concapt  has  sinplici-y  as 
its  major  advantage.  Control  and  update  problems  are  mini- 
mized since  all  the  data  are  located  at  a  singl?  node. 
Erawbacks  of  this  strategy  include  pctenxial  problems  of 
reliability  or  a  vailabili-^y .  If  the  central  node  fails,  the 
system  is  down  completely.  If  there  is  a  high  voluir.e  of 
communications  with  the  central  node,  there  may  be  bottle- 
necks which  slow  down  system  response  time.  Depending  upon 
the  aicunt  of  secondary  storage,  there  might  also  be  a  limi- 
tation on  the  possible  size  of  the  database.  These  ccnsid- 
eraticns  are  applicable  to  each  Ian  but  are  not  of  ccrcsrn 
for    the    SPLICE    systei  as   a    whole, 

2  •      Partitioned 

Kith  the  partitioned  database  distribution  strategy 
there  is  still  only  one  copy  of  the  database  however,  it  is 
divided  into  disjoint  subsets  or  partitions  which  are 
assigned  to  particular  nodes  in  the  system.  With  this 
approach,  the  size  of  the  database  is  not  limited  to  the 
amount  of  secondary  storage  at  a  central  node  but  is  the  sum 
of  the  tot cl  storage  available  within  all  nodes  of  the 
system,  Eetrievals  and  updates  present  less  of  a  problem 
since  ttey  can  be  directed  to  the  particular  node  where  the 
data  are  located.  Access  to  the  local  database  partitions 
lessens  the  possibility  of  bottlenecks  and  may  reduce  commu- 
nications costs.  If  the  reguirements  are  for  data  located 
outside  of  the  local  node,  communications  costs  are  greater 
and   the    delay   in   response  time   also   increases. 

Ihe  benefits  of  the  partitioned  approach  are  highly 
dependent   upon    the   location    of      the   data    required    to    satisfy 


user  requests.  This  is  als  c  krcwn  as  locality  of  r^frr'?nc  =  . 
There  is  a  high  degr€e  of  locality  of  reference  if  -he  data 
is  partitioned  such  that  the  data  at  a  particular  nod^  is 
used  almost  exclusively  by  users  at  that  node.  If  -^-his  is 
not  optimized,  database  availability  is  limited  in  the 
system.  With  the  partitioned  approach,  reliability  of  the 
system  is  improved  ever  the  centralized  approach  because 
failure  at  one  node  only  causes  a  performance  degradation, 
not  failure  of  the  whole  system.  In  contrast,  the  avail- 
ability of  the  entire  database  is  less  likely  because 
failure  of  any  node  in  the  system  is  more  probable  "han 
failure  of  -^.he  central  node  in  the  system.  The  partitioned 
strategy  is  most  appropriate  in  a  distributed  environment 
where  there  is  a  linitaticn  on  secondary  storage  at  the 
central  node,  where  reliability  of  the  system  must  be 
improved,  or  where  there  is  a  possibility  for  operating 
efficiencies  to  to  be  gained.  A  high  degree  cf  locality  of 
reference  in  database  access  patterns  implies  that  operating 
efficiencies  can  be  gained  through  partitioning  of  the  data- 
base. Within  the  SPLICE  environment,  determining  the 
cptiial  partitioning  strategy  to  ensure  system  efficiency 
poses  a  difficult  prctlem. 

3 .   Peclicated 

In  the  replicated  distribution  strategy  each  node 
within  the  system  is  allocated  a  complete  copy  of  the  data- 
base. The  network  database  management  system  is  responsible 
for  coordinating  the  multiple  copies  of  the  database  but 
there  is  not  a  problem  cf  determining  which  nodes  have  which 
part  of  the  database  as  there  is  with  the  partitioned 
apprcach.  The  replicated  approach  is  most  advantageous  in 
the  areas  of  reliability,  availability  and  retrieval 
respcnse  time.  As  with  the  centralized  approach,  the  size 
cf  the  database  may  te  limited   by  the  size  cf  the  seccndary 
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storage      at    each      node.  Faster      respcnse    times      fcr      ussr 

requests  are  possible  because  there  is  no  need  to  gc  outside 
of  a  particular  node  for  database  access.  This  also  i.T.clies 
that  ccmirunica ticn  costs  would  be  cheaper  as  most  network 
coramunicaticn      wculd      be   localized.  Hirh      the      replicated 

approach,  reliability  is  high  in  terms  of  data  availability 
and  if  a  particular  ncde  fails,  there  is  no  lest  portion  of 
the  database.  Another  copy  of  the  complete  database  could 
te  generated  from  a  reighbcring  node.  This  simplicity  of 
backup  and  recovery  operations  is  another  of  the  advantages 
of  the  replicated  approach.  If  a  node  within  the  system 
fails,  there  must  be  controls  in  the  updates  that  may  be 
performed  tc  maintain  the  integrity  of  the  database.  This 
is  tc  say  that  independent  updates  of  separate  nodes  must 
not  te  allowed  or  there  will  be  likely  data  inconsistencies. 
Locking  mechanisms  must  be  employed  to  ensure  data 
integrity. 

The  replicated  distribution  strategy  is  most  appro- 
priate where  the  database  is  not  too  large,  reliability  is 
critical  to  the  system  and  inefficiencies  of  updates  can  be 
accepted.  This      implies      a     retrieval-intensive      database 

system.  The    amount      of      overhead      for   communications      and 

processors  needed  because  of  synchronization  and  control 
complexities  in  a  replicated  system  is  dependent  upon  the 
level  of  consistency  required.  Within  the  SPLICE  system  the 
data  dictionary  should  be  fairly  static  once  implemented. 
Rith  only  limited  update  requirements,  the  replicated 
strategy  for  the  SPIICE  data  dictionary  is  the  reccmmended 
approach. 

U  .      H vbr^J. 

The  hybrid  distribaticD  strategy  is  a  combination  of 
the  partitioned  approach  and  the  replicated  approach  tc  data 
distribution.         The      database   is      partitioned   into      disjoint 
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subsets  hcfeisvar,  ir.  this  strategy  there  may  be  ssvsral 
replicated    partitions.  Each    part    of      -he   database      can   be 

replicated  any  number  of  times  and  each  node  may  have  "hat 
portion  of  the  entire  database  which  optimizes  performance 
at  that  node.  This  strategy,  if  properly  implemented  with  a 
high  degree  of  locality  of  reference,  should  limit  the  need 
for  node  to  node  communications  thus  reducing  C':;£~.s  and 
potential   ccmmunicat ions   bottlenecks.  The    hybrid    strategy 

improves  the  reliability  of  the  system  over  the  strictly 
partitioned  approach.  The  key  advantage  of  th<=  hybrid 
approach  is  flexibility  in  how  the  data  are  stored.  Nodes 
with  liiited  secondary  storage  may  tailor  their  partition 
for  functional  opti  irization  whereas  nodes  which  demand  a 
high  degree  of  reliability  and  faster  response  times  n-ay 
duplicate  a  larger  portion  of  the  database  tc  satisfy  their 
needs. 

The  flexibility  provided  by  the  hybrid  approach  is 
achieved  at  the  cost  of  system  software  complexity.  The 
network  EEMS  must  not  only  keep  track  of  where  data  exist  in 
the  network  but  it  nust  also  be  capable  of  synchronization 
cf      the        data       updates.  Query      optimization        and      query 

processing  are  nontrivial  tasks  in  the  hybrid  environment. 
Because  cf  the  software  complexity  necessary  to  iiplement 
the  hybrid  strategy,  the  question  is  whether  the  flexibility 
to  be  gained  by  this  approach  is  worth  the  tradeoff.  A 
likely  candidate  for  the  hybrid  approach  might  be  a  system 
with  a  large  database  that  has  only  a  few  nodes  capable  of 
handling  a  replicated  approach  and  where  high  reliability  is 
essential  in  the  nodes  which  have  the  secondary  storage 
capacity   to    accommodate   a   large    portion    of    the  database. 
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J.       SiaMTLE    OF    TANDEH    DATA    EICTIONARY    FIL2S 

Th€  following  schema  consists  of  20  objects  (18  dsfi-i- 
tions  and  two  records)  ,  Thes?  objects  will  b'S  used  to 
construct  an  example  for  the  SPLICE  dictionary  and  its 
related  fil=s.  [Hef,  13]  was  used  as  a  format  guidG  and  for 
€xplainaticn  of    the    files   which   follow. 


7C0M MINTS 


*  Dccument    Number    uniquely    identifies   requestor,    date    and 

*  local    serial    number. 

EEF        EOCNOW  HEADING    "Document   Number" 

PIC    S. 
PIC    5(5). 
PIC    9(4    . 
PIC    9{U    . 


EOCNOW 

02 

Servic 

a 

02 

Unit    I 

d  Code 

02 

Julian 

date 

02 

Serial 

nu  m 

ly    indentifiec    within   the   Federal    Supply    System 


DEF         N3N  HEADING    "Nat'l    Stock   Number". 

02      Fed   Sup  Class        PIC    9(4). 
0  2      NIO  TYPE    *• 

*  Document    Identifier   which    indicates    the    Dur^oss    and    use   of 

*  the    document     (i.e.,    requisition,    referral,    rollow-up, 

*  status,    etc.).    The    Document    Identifier   is   a   mandatcrv 

*  entry    en    eacn    milstrip   document. 

EEF  EOCID  PIC    AXX  HEADING    "DOCUflENT    IDENTIFIER" 

*  Routing   identifier    is   used  to   represent   the   address   of   the 

*  inter.ded    recipient    cf   the    document;    to    denote    the    actual 

*  consignor   of    ma-erial;    or    to    identify    the  supply    activity 

*  originating  the   action. 

DEF  ROCTID  PIC    AX9  HEADING    "ROUTING    IDENTIFIER" 

*  Forecast    level   of    excected   demands   for   next    auarter 

*  according   to    demand    Jor   the    past    six    months." 

DEF         DMDFOEECAST         PIC    9(4)  HEADING    "DEMAND/FORECAST" 

*  Hinium   items    on   hand   to   meet   war   reserve    requirements. 
DEF  RESERVATION         ilC    9999         HEADING    "RESERVATION" 

*  A    stcckinq   level    that    is    computed    by    adding    demand    during 

*  lead   time'plus   safety   stock. 
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DEF    RECRDEBPOINT   EIC  9(U)     HEADING  "REORDER/POINT" 

*  A  managerial  technique  used  to  protect  against  a  stcckout. 

*  An  order  can  be  computed  and  placed  so  -nat  the  delivery 

*  will  arrive  when  a  certain  level  of  inventory  is  still 

*  there. 

DEF    SAFETY  LEVEL   TIC  9(4)     HEADING  "SAFETY/LEVEL" 

*  Numher  of  units  that  have  outstanding  requisitions  agair.s- 

*  them. 

DEF    BACKCEDER      IIC    9(5)     HEADING  "3ACK0FDER" 

*  This  gives  the  general  category  of  a  part,  i.e.,  resistor. 
DEF    PART  NAME      PIC  A ( 1 C)   HEADING  "PART/NAME" 

*  The  Media  Status  Cede  indicates  the  recioient  of  stat'js 

*  and  the  means  of  transmission. 

DEF    MEDIA  STATUS   PIC  X       HEADING  "MEDIA/STATUS" 

*  This  two  digit  alpha/numeric  figure  identifies  who  has 

*  inventory  and  technical  responsibility  for  an  item. 

DEF    ACCOUNT/COG    PIC  XA       HEADING  "ACCT/COG" 

*  Priority  combines  the  assigned  force/acuivi ty  designator 

*  and  the  accropriate  urgency  of  need  designa-or  and  enables 

*  the  r equisit ioner  to  determine  -he  approcriate  priority 

*  code. 

EEF    PRI  PIC  99       HEADING  "PRIORITY  CODE" 

*  Expected  means  of  transporting  items,  and  received  in 

*  shimpnent  status  documents. 

EEF    MOEE  PIC  X       HEADING  "MODE  0?  SHIPMENT" 

*  National  Item  Identification  Code  uniquely  identifies  a 

*  line  item  within  the  Federal  Supply  System. 

EEF    NUN  PIC  9(9)    HEADING  "NUN" 

*  A  description  of  the  types  of  units  under  which  material 

*  is    issued. 

DEF  ONIT    CF    ISSUE       PIC    AA  HEADING    "UI" 

*  Cost   of    an  item   per   unit    cf   issue 

EEF         UNIT    PRICE  PIC    9(6) VS9       HEADING    "UP" 

*  Number  cf   items  of    the   ob;iect    per   unit   of  issue   that    are 

*  physically  located   at   that    particular   stock   point. 

DEF  QTY    ON   HAND  PIC    99999  HEADING    "ON/HAND" 
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*  PHIMJHT!-KnY   =     COCNDK 

*  ALTZRNii.TS    K2Y    =    NSN 

BECOED       EHr         FILE    IS    "$DAT A, SDPPLY . DHF" 


KEY-SEQUZNCZD 


02  CIC 

0  2  NSN 

02  ACCT/COG 

0  2  EOCIiU:i 

02  BIC 

02  FBI 

0  2  QZY    ON    HAND 

*  KEY    IS    EHF.DOCNOM. 

*  KEY  "N£"  IS  DHF.NSK. 

IND 


TYPE  DOCID. 

TYPE  *. 

TYPE  *. 

TYPE  *. 

TYPE  *. 

TY^E  *. 
PIC  9(U) 


HEADING  "ON/HAND". 


*  ?3IKiiR1-FrY    =     NSN 

*  ALTFENATE    KEY    =    PABT    NAME 


OBD 

MSIB.       FILE    IS 

02 

NUN 

02 

PABT   NAME 

02 

EOBEOSE    CODE 

02 

EATF   ACTION 

02 

EATE   IN7 

02 

UNIT   PBICE 

02 

CTY    ON    HAND 

02 

BFOBDSR    POINT 

02 

UNIT   0?     ISSUE 

02 

BESERVATION 

02 

EACKOEDSB 

02 

EEMAND     FORECAST 

02 

SAFETY    LEVEL 

02 

LEAD   TIME 

TYPE    *. 

TYPE    *. 

PIC    A 

PIC    9(4) 

PIC    9  (4) 

TYPE    *. 

'''YPE    *. 

TYPE 
TYPE 
TYPE 
TY^E 
TYPE 
TYPE 
TYPE 


KEY-SEQUENCED 


HEADING  "PURPOSE    CODE" 

HEADING  "DATS    LAST    ACT" 

HEADING  "DATE    LAST    INV" 

DISPLAY  "M<zzz,zz9. 99>". 


KEY    IS    MSIE.NSN. 

KEY    "FN"    IS    MSIS.PARTNAKS. 

END 


is   an   unstructured 
ields  that    hav*?   any 


Th<=    Dictionary    Definition   File    (DDF) 
fil<=    ccrtaining    only   one   record.  The 

meaning  are  NEXT-OBJFCT  and  NEXT-TEXT-ID.  There  are  5  ether 
fields  that  give  DDL  version  ir.f  crma  tion.  The  NEXT-OEJECT 
is  a  ccunter  the  DDL  compiler  uses  to  assign  object  numbers 
to  objects  (the  scheia  previously  given  has  20  objects —  18 
definitions   and      2    records)  as    they      are    entered      into   the 

dictionary.  This  field  will  be  incremented  by  one  each  time 
an  object  is  added  and  this  new  value  is  assigned  as  the 
cbject   number  of  the    new  object. 

The    NEXT-TEXT-ID    is   used   by   the    DDL    compiler    in    the   same 
manner      as      the      NEXT-OBJECT.  Dictionary      comments,         PIC 
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strir.gs,        HEADINGS    strings,        DISPLAY      strinas,       and      VALU2 
literals    are  all  text   itams.      The   prsvicus    schema    has 
75    text      items    and      therefore   the   -sxt      co un-    stands      a-    75. 
Iigur€    3.2,    shews    how  this    file    would    look. 


NEXT 

CEJJCT 

20 


NEXT 

TSXT-ID 

75 


DICTIONARY 

y EPS  ION 


Figure   3.2        Dictionary   Definition   File. 

The  Object  Definition  File  (OD?)  is  a  k<=y-s9quenc5d  file 
that  contains  on=  record  for  every  object  entered  intc  the 
dictionary.  Figure  3.3  shows  this  file  according  tc  the 
schema      previously   given.  The    ODF      file      uses    the      otjecT: 

number    from     the  DDF     to   identify      the   object.  The   object 

number  is  followed  by  object  name  with  an  object  type 
(either  ID  the  symbol  for  definitions  or  RD  the  symbol  for 
records) .  The      COMHENTS-      TEXT-      ID      field      is      used      for 

dictionary  comments  associated  with  the  entire  RECORDS 
(comment  lines  that  immediately  precede  a  RECORD  stat'=3ient 
in  the  DDL  source  schema).  The  values  are  assigned  by  the 
EDF. 

The  Object  Build  list  (OBL)  is  a  key-sequenced  file  that 
contains  one  record  for  each  element  of  each  object  in  the 
DDL  scheia.  The  reccrds  are  identified  by  the  object  number 
that      they      received    in      the      OD?.  An   element      number     is 

assigned  that  identifies  each  element  within  an  object.  A 
complete  description  cf  an  eleirent  can  be  obtained  from  the 
CBL    record    (i.e.,   the   elements   name,    data    type,    size,    offset 
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OEJECT 

CBJSCT 

OBJECT 

COMMENTS 

NC?1B1R 

NAME 

II?2 

TEXT^ID 

1 

DOCNUa 

ID 

2 

NSN 

ID 

^ 

COCID 

ID 

4 

ROUT IE 

ID 

5 

DEMAND    FORECAST 

ID 

6 

RESERVATION 

ID 

7 

REORDER    POINT 

ID 

8 

SAFETY    LEVEL 

ID 

Q 

HACKCRDER 

ID 

10 

LSADTIME 

ID 

1 1 

MEDIA    STATUS 

ID 

12 

FUND    CODE 

ID 

13 

PRIORITY 

ID 

m 

MODE 

ID 

15 

NUN 

ID 

16 

UNIT    CF    ISSUE 

ID 

17 

UNIT    PRICE 

ID 

18 

CN-HAKD 

ID 

19 

DEMAND    HISTORY 

RD 

61 

20 

MASTER    STOCK 

RD 

6a 

.._     .  ..  _          _ ,  -     .-J 

Figure    3.3        Object    Definition   File. 

withir.  the  cbjectr  and  text-id  number).  Figure  3.U  shews 
how  the  OBI  element  records  are  linked  to  the  ODF  for  a 
typical    cbj€ct,    the    DEMAND    HISTORY   FILE    record. 
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I  he  Cbi€ct  T9xt  File  (OTF)  is  a  !c5y-s-=qu  ancsd  fils  tha- 
contains  cne  reccrd  for  each  line  of  input  of  a  dictionary 
COMMENT,  HEADING  string,  DISPLAY  string,  PICTURE  string,  and 
VALUE   literal    in   the    DDL   schema.  Th?    OBL   links    to    the    CT? 

en    TEXT-ID    fi3lds,       one    to    many.       Figure    3.5    shows    s    partial 
layout    ficm   the    previous   schema. 


NUK3^ 

LINE 
NUMBER 

TX 

TEXT 
LINE 

1 
1 
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3 
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c; 
•J 

6 

7 
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7 
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0 
1 
0 
0 
0 
0 
0 
0 
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2 
ti 

c 
c 

H 
P 
P 
P 
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c 
c 
c 

«l 

DOCNUM    IDENTIFIES    REQS 

DATE    AND    LOCAL    SERIAL    NUK 

DOCUMENT    NUMBER 

A 

9(5) 

9(Ui 

NATIONAL    STOCK    NUMBERS 
ARE    CLASSIFIED    BY    A    1 3 

nTf'"T'T'       MFTMn'ZrO  —  —  —  — —  ____ 

11 

ft 

It 

n 

It 

67 
68 

i__ 

0 
0 

H 
D 

UNIT/PRICE 
M<zzz,2z9,99> 

Figur€   3.5        Object   Text   File. 


The  Reccrd  Defiiition  File  (RDF)  is  ke y-saquenced  and 
contains  one  record  for  each  RECORD  in  the  DDL  schema.  The 
object  nuaber  assigned  to  the  RECORD  through  the  CDF 
uniquely  identifies  each  record.  The  RDF  record  also 
contains  a  DEF- NUMBER  and  if  the  record  has  been  defined 
with  a  EEFINITION  IS  clause  then  DEF-NUMBER  will  hold  the 
object  number  of  the  DEFINITION.  If  this  is  not  true,  tren 
the  EZF-NUMBER  assuies  the  object  number  of  the  RECCRD 
itself.  The  file  type  and  file  duration  fields  give  details 
to  the  structure  of  the  RECORD  (i.e.,  unstructured,  rela- 
tive, entr y-sequenced ,  key  sequenced)  and  the  permanence  of 
the    RECORD.        The   RDF   links    back   to      the    ODE    one    to    one   dIus 


■^,he    BEF    links      tc   th€  OBL  one      tc   many.      Figure    3.6, 
sxairpls    cf    this    file. 


BFCOFE  DEF  TANDEM  FILE  FILE  EEC 

^D«3^R  NUJIHEH  JILE    NIJIE  IIRI:  DUH  LTH 

19  19  ICATA. SUPPLY. DHF  3  0  Ul 

20  20  SEATA.  SUPPLY.  MSIP.  3  0  59 


Figure    3.6        Record   Definition   File. 

The  Key  Definition  File  (KEF) ,  is  also  key-sequencec  and 
contains  one  record  for  each  primary  key  and  each  alternate 
key  declared  for  each  record  in  the  schema.  The  identifica- 
tion cf  the  KDF  record  comes  from  the  object  number  that  has 
teen  assigned  by  the  OBL.  The  RDF  links  to  the  KDF  on 
BECOP.D-ND«EER,  one  to  many  and  KDF  links  -c  the  OBL  by 
EEF-NDMEER/EEF  ELEMENT  one  to  cne.  This  layout  is  shown  in 
figure    3.7 
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Figure    3.7        Key   Definition   File. 

With      the         dictionary      files      described        and      examples 
provid€u,    it  is    important  tc   realize    that   these    files   can   be 
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linked  through  primary  and  alternate  keys.  This  cipaoili-ty 
provides  the  DBA  yith  a  complsta  picture  of  ths  data 
elements  within  the  supply  system.  Figure  3.8  shows  cn'r  set 
cf    pcssitls   linkages      between    the    dictionary    files.  Ey    no 

means  does  -^his  diagram  show  all  possible  links  bc'^ween  the 
files. 
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)2  DEF- NUMBER 
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32     'DENTlFiER 

33     RECORD- NUMBER 

03      ELEMENT 
02     38L-^EY 

03     OEF- NUMBER 

03     ELEMENT 
02     KEYTAG- VALUE 
02     KEYTAG- STRING 

REDEF.NES  KEYTAG-  VALUE 
02     FIELD 

03     OFFSET 

03     SIZE 
02     NU'vi.  -  FLAGS 
02      NF 

RECEF'NES  NULL-  FL-aGS 

03       .ALUE 

03  SIZE 
OJ  FLAGS 
02     FijiG-aYTES 
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33     -EY-CL^SS 
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Figure    3.8       Dictionary   Structure. 
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IV.  CSSIGN  OF  A  SPIICE  DIBECTOHY  BASED  UPON  TAIIDEM  DEJS 

a.   EIBECTOBY 

Th€  software  package  that  formulates  -he  data  dictionary 
does  a  good  job  of  describing  each  data  element  (i.e.,  -^ells 
what  it  is)  but  it  does  little  to  tell  a  us<=^r  -^he  location 
of  each  data  element  (i.e.,  where  it  is)  wi-hin  the  SFLICE 
system.  Without  the  capability  of  retrieving  this  directory 
inf  oraiaticn ,  the  present  layout  of  the  data  dictionary 
cannot    satisfy    the    following   queries: 

•  What  locations  in  the  network  stock  item 
59C5-00-255-3699,   resistor,    fixed,    composition? 

•  Who  is  the  inventory  iranager  who  holds  technical 
resf cnsibilit y  and  what  is  the  latest  status  for  a 
particular    electronic    tube? 

•  Rho  is  the  manufacturer  of  an  item  and  where  is  this 
irenuf ac-^ur er   located? 

Even  though  all  of  these  questions  can  be  answered  in  a 
matter  of  time  by  any  of  the  UADPS-S?s  manually,  they  canno- 
be  answered  on-line  by  use  of  the  proposed  SPLICE  system, 
the  ENCOMPASS  DBMS,  or  the  data  dictionary.  The  development 
cf  a  "custoir.ize  d"  data  directory,  to  be  defined  using  the 
EDL  offered  by  the  TANDEM  DBMS,  is  suggested.  Easically 
this  wculd  be  the  same  as  defining  a  database  through  the 
capabilities  of  the  DDL.  Once  this  directory  has  been 
created  and  is  in  use,  the  data  dictionary  itself  can  be 
queried  ty  ZNFORM  tc  obtain  information  abour  the  directo- 
ry's data  structure  and  location.  Creation  of  a  simple 
directory  is  the  foundation  of  the  concept.  As  technology 
improves  and  the  directory  becomes  a  more  useful  software 
tool,    its   capabilities  no   doubt    will    ba   expanded. 
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The  directory  *hich  is  to  be  defined  is  or. €  -I'.-.Lct 
contains  the  necessary  information  thac  will  answer  th-  too 
ten  or  fifteen  questions  at  a  local  stock  point.  These 
questions  are  most  likely  to  be  about  line  iterr.s  (r=r:=ir^- 
bles  cr  consumables),  their  location  within  the  system, 
quantity  on  hand,  manufacturer,  and  who  has  control  cvsr  the 
items  within  the  Navy  Supply  System.  To  answer  these  ques- 
tions the  directory  must  store  information  afcout  the  basic 
aspects    cf    line      iteirs   within   the   system.  Line    i-ems    will 

xanqe  from  repairables  for  ships,  airplanes,  and  machinery 
to  consumatles  suet  as  screws,  bol-s,  and  clo-hinq. 
Therefore  it  is  assumed  that  this  directory  will  contain 
informa-ion   about   inventories   and   locations. 

The  TANEEM  DBMS  uses  a  relational  approach  in  defining  a 
database  and  that  fits  our  needs  well.  The  relational 
approach  to  data  is  based  on  the  realization  that  files  r hat 
obey  certain  constraints  may  be  considered  as  mathematical 
relations,  and  hence  that  elementary  theory  about  mathema-*:- 
ical  relaticns  may  b€  brought  to  bear  on  various  practical 
problems   of   dealing    with   data   in   such    files   [Ref.    15], 

E.       EATA    ELEMENTS    FOB    THE    DISECTORY 

The  files  within  the  directory  must  store  information  on 
several  aspects  of  the  line  items:  siock  item  identifica- 
tion, location  of  manufacturer,  and  stock  point,  location. 
The  information  describing  each  of  these  areas  of  the  supply 
system    is   shown    in    table   IX,    table    X,    and    table    XI. 

C.       fILE    STBOCTUESS 

As  mentioned  earlier,  all  the  files  in  the  directory  are 
defined  as  relational  files  that  are  uniquely  defined  by  the 
value  stored  in  its  primary  key  field.  With  a  primary  key 
value   assigned,      ENSCBIBE,      the      database   manager    of  TANDEK, 
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T13LE    IX 
StocX   Itsa    Identification 

•  NATIONAL    STOCK    NU:^.B  ER  *    ACCO  UNT/COG  !^IZ  A^IC: 

•  MANUFACTURER    CODE    NDIIBZR  *    NOUN     NA'IE 

•  PART    NUMBER  *    UNIT    0?    ISSUE 

•  SPECIAL     MATERIAL    ID    CODE  *    SITE    NA:1E 

•  LOCATIONS  *    ITEt^    ilANAGER 

•  TECHNICAL    RESPONSIBILITY  *    PRICE 


TABLE    X 

Sanufacturer  File 

MANUFACTURER 

CODE    NUMBER            *    ORDER    NUMBER 

MANUFACTURER 

NAME                                *    ORDER    DATS 

LOCATIONS 

*    EST    DELIVERY 

DATE 

PARTNA?1S 

*    PART    NUMBER 

SALES    PERSON 

*    PHONE    NUMBER 

can  rar.dcilv  pcsitior  itself  anywhere  within  these  file's  for 
a  rea-f,  write,  or  update  operation.  Another  step  in 
defining  each  file  is  to  evaluate  what  data  elements  cther 
than  the  primary  key  will  frequently  be  used  as  access  paths 
into  the  files.  If  these  data  elements  are  assigned  as 
alternative  key  fields,   then   ENSCRIBE  can  selectively  read 
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T13LE  XI 
Stock  Point  Location  File 


NATIONAL  STOCK  NUMBER 
CDANTITY  ON  EAND 
LOCATION 
FZCF.DER  POINT 
OUTSTANDING  PEQUISITIONS 
SUPPLY  CONDITION  CODE 
PURPOSE  CODES 
HOLE  CODE 


*  SITE  NAME 

*  UNIT  OF  ISSUE 

*  PRICE 

*  BACKORDEE 

*  SAFETY  LEVEL 

*  REPAIR  STATUS 

*  MODE  OF  SHIPMENT 

*  PERSONNEL  DIRECTORY 


records  frcm  the  files  en  the  basis  of  either  full  or 
partial  alt<=rnativ9  >~y  values.  Thess  keys  are  not  required 
to    be    uniqu€  [Ref.     13]. 

1  ,      Stock   Item    Id^ntifi cation 

The  Stock  Iteic  Identification  inf orniatior.  is  broken 
into  three  files:  line  itecns,  stock  location,  and  material 
control.  The  data  elements  within  these  files  describe  what 
line  iteirs  are  stocked  in  the  Navy  Supply  System,  where 
these  items  are  stocked,  and  who  has  been  assigned  the 
overall   responsibility   of  each   individual    line  item.      Figure 


U,  1       shciis      the      information 


m 


eacn 


:ile , 


primary      ana 


alternative    keys  and   the   linkage    between   the    files. 

2-      Manufacturer   File 

The  manufacturer  file  uses  three  files  identified 
as:  manufacturer,  order,  and  order  description.  These  files 
hold  infcrmation        pertaining  to        the  manufacturer 
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LINE    ITEMS 

♦*•  HATIONAL   STOCXNIJMSEB 
»  PAST  NUMBER 
HCXM  NAME 

SPECIAL  MATERIAL   ID  CODE 
«AMJfACTUft€R   NUXBER 
ONH  Of    ISSUE 
PRICE 


MATERIAL  CONTROL 

*    ITEM  MA>4AGCR 
LOCATION 

TECHNICAL  RESPONSIBILITY 
LOaTICW 
*♦  ACC0W<T/C0O<IZAXI 


STOCK  LOCATION 

•♦  P9!>«EY 

-ACCJXJMT/COGNIZA^tfE 
-NATIONAL   STOCX   HUX8ER 
t  SITE   HA>€ 
LOCATION 
-AODRESS 
-CITY 
-STATE 


♦*  PRIMARY  KEY 
*  ALTERNATE  KEY 


M    ^ 


■*  ONE   TO  ONE   LINK 
♦  MANY   TO   ONE   LINK 


Pigure    4.1        stock  Itea   Identification. 

identification  and  location,  orders  outstanding  with  that 
manuf actrrsr,  and  when  these  crdsrs  are  to  be  delivered. 
Ihey    will   also    show    what   part   these    orders    are   for,    how    much 
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they  cc£t,  and  with  whcm  this  ordar  was  placsd.  Fiqur^  '4.2 
represents  *-his  structure  with  the  k^ys  identified  plus  *h  = 
relationships  between  these  files. 


MANUFACTURER 

••  KAMUf ACTOfiER  NU«9ER 
♦  MANUf ACTUfiCH  NAME 
LOCATION 
-AODRESS 
-CITY 
-STATE 
-PHO>€  NUNSER 


ORDER 

**  CROCR  NLA«ER 

ORDER  DATE 

-MONTH 

-OAY 

-YtAR 
EST  DELIVERY  DATE 
*  MANUFACTURER  NUN8ER 


♦♦  PRIMARY  KEY 
*  ALTERNATE  KEY 


*  < 


ORDER   DESCRIPTION 

♦♦  PRIMKEY 

-ORDERNW 
-PARTMUM 
*  PART  MAXE 
SALES  P€SSOW 
QUANTITY 
PRICE 


■*    ONE   TO  ONE  LINK 
■♦    MANY   TO  ONE   LINK 


Figure   A. 2        Jianufacturer   File. 
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3  •      St cck   Point    Iccation    File 

The  informaticn  needsd  in  this  file  is  divided  into 
three  files  that  are  labelled  invenrory  detail,  si-^-r  direc- 
tory, and  status.  These  files  would  give  the  requesx.or 
detailed  information  en  each  stock  item  That  is  carri'=d  by 
this  particular  activity,  a  directory  of  the  personnel 
within  the  activity  stock  point,  and  the  status  of  any  docu- 
Eents  of  the  requestor  that  iright  have  been  passed  to  this 
activity.  Figure  4.3  shows  these  files  and  how  they  relate 
to    one   another. 

B.       D3PECTCBT    DISTRIEDTION 

The  question  of  which  distribution  configuration  to  use 
in  locating  this  directory  within  the  SPLICE  project  can 
best  he  handled  by  deciding  the  characxer ist ics  of  the 
data/information  to  be  controlled  by  the  directory.  The 
data  within  the  defined  SPLICE  directory  can  be  classified 
as  either  static  or  dynamic  when  considering  updates 
[Ref.  16].  The  static  classification  does  not  mean  the  data 
cannot  chance  but  changes  occur  infrequently  and  therefore 
this  type  of  data  presents  few  problems  in  controlling  data 
integrity.  On  the  ether  hand,  dynamic  data,  that  is  data 
with  a  low  to  high  update  rate,  presents  a  challenge  wren 
trying   to    maintain    data    integrity. 

E.       SISTIC    OR    DYSAflIC 

The  SPLIC2  directory  that  has  been  defined  consists  of  a 
combination  of  data  that  has  static/dynamic  updates.  Within 
this      area   of      concern   are      several  classes      of   data.  The 

classes    are   divided    according   to    the   complexity   of   the 
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• 


STOCK  ITEMS 

*♦  NATIONAL  STOCK  NUMBER 
♦  SITE  NAME 

QUANT IT y  ON  HAND 
PRICE 

BACKOROER  . 
SAFETY  LEVEL 
OUTSTANDING  REONS 
SUPPLY  CONDITION  CODE 
REORDER  POINT 


STATUS 

rtr  ROUTING  ID  CODE 
*  DOCUMENT  NUMBER 
STATUS  CODE 
HOLD  CODE 
MODE  CF  SHIPMENT 


STTF  DIRECTORY 

*♦  SITE  NAME 
♦  ROUTING  ID  CODE 

CUSTOMER  SERVICE  DIVISICH 
-PHCNE  NO* 
-PERSONNEL 
MATERIAL  DIVISION 
INVENTORY  CONTROL  DIVISION 
AVIATION  SUPPORT  DIVISION 


*•  PRIMARY  KEY 
*  ALTERNATE  KEY 


<•  <■ 


-^    ONE   TO  ONE  LINK. 
■^MANY  TO  ONE  LINK 


Figure   4.3        Stock    Point   Location   File. 

updates.      These  classes   of    updates    range    from   CLASS    0    (i.e., 

data    which    does  not    change)     tc   CLASS   U    (i.e.,    data    fcr    which 

an      update    may  trigger   an      action   in      a    different      machine) 
[Ref.    16]. 
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Ih8  data  that  would  b^  loc3t<=d  in  the  stock;  it«ni  ider.-i- 
fication  fil€s  meats  the  definition  of  static  upda-.TS  ar.d 
contains  CLASS    1    data.        Updates   to   th9    data    in    this    ccriion 


ot 


jr      4. 


he    directory   would    be   made    by   additions,      d9l-=ticr. s , 


or 


replacement  and  would  most  likely  be  made  via  batch  niode. 
Simple  updates  of  data  such  as  these,  if  performed  twice, 
cause  very  little  harm.  The  data  in  the  manufacturer  files 
would  be  grcuped  in  the  dynamic  category  with  updates  being 
fairly    lew    and    ccntairing  CLASS    2    data.         This  class   of   data 


a      little   more       sensitive      to      updates    and      any 


P  da  t  es 


applied  twice  could  cause  the  loss  of  data  intsgrity. 
Update  transactions  in  this  area  would  involve  cancellations 
cf  orders  or  possible  changes  in  the  quantity  ordered.  If 
repeated,  this  would  mean  the  loss  of  data  integrity.  If 
the  ufdate  is  only  delayed  but  not  lost,  there  would  be  no 
harm.  A  simple  control  technique  of  assigning  a  serial 
number  to  each  update  transaction  would  ensure  that  no 
transaction  is  lost  or  double-processed.  The  stock  point 
location    data      is   alsc      dynamic   in      nature    but      with   a      high 


upd: 


;e    rate. 


The    data   is      categorized    as   CLASS      3    meaning 


that  the  data  is  very  sensitive  to  tiae-critical  updates. 
Dpdates  in  this  area,  if  reapplied  at  a  different  time,  may 
not  have  the  same  effect.  For  example,  if  the  quantity-on- 
hand  field  shows  100  EA  in  stock  for  a  particular  screw  but 
the  recent  issue  of  50  EA  is  not  reflected  before  a  request 
for  75  EA  ccmes  in  frcm  ancther  activity,  the  requestor  is 
going  to  stop  looking  since  he  thinks  his  demand  can  be 
satisfied  by  this  activity.  In  actuality  he  needs  to  find 
an  activity  that  has  25  ZA  mere.  A  control  technique  that 
can  be  applied  is  the  use  cf  times-amps  to  ensure  that 
transactions  are  not  processed  in  an  invalid  sequence. 
Serial  numbers  may  be  needed  as  well  as  timestamps  to 
prevent  loss  or  double  processing  of  transactions  on 
recovery   [Ref.     17]. 
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The  ccr.capt  of  sysrem  architecture  and  th<=  natwcrc 
datatase  inar.agement  system  software  deciding  the  distribu- 
tion strategies  for  dictionaries  also  holds  true  for  -h= 
distribution  of  directories.  Ihe  four  types  of  distribution 
strategies  which  where  discussed  in  Chapter  III,  along  with 
their  advantages  and  disadvantages,  similarly  apply  tc  th« 
directory      portion    of      the      DDS.  Of   the      four      strategies 

mentioned,  it  is  sugcested  that  the  hybrid  solution  be  given 
the  ircst  attention  though  its  inherent  complexity  is 
ackncwle  dge  d. 

I.        EIEEID    SOLnTION 

A  hybrid  solution  is  one  where  multiple  copies  of  the 
subsets  cf  the  directory  are  replicated  within  the  network 
and  each  node  may  have  a  partitioned  fraction  of  the 
directory  [Bef.     16]. 

Kith  this  description  in  irind  it  is  suggested  that  the 
stock  identification  files  and  the  manuf act ureer  fil9s  be 
replicat€d  at  the  inventory  control  points  located  at  ASO 
FHILAEZFKIA      and    S?CC      MECHANISBDRS    plus       NSC    NORFOLK,  NSC 

CAKLANE,  and  NSD  SDBIC  BAY.  Ihe  stock  point  location  files 
would  then  be  be  partitioned  at  each  QADPS-S?  activity  that 
held  line  items  for  issue.  The  justification  behind  this 
type  cf  distribution  falls  back  to  the  characteristics  of 
the  updates  toward  each  file,  and  the  differences  in  data  at 
each  site.  Sines  the  first  two  files  will  experience  static 
or  low  volume  updates  and  therefore  is  less  likely  to  have 
high  volume  of  communication,  the  problems  concerning  reli- 
ability, response  tine  for  both  retrievals  and  updates,  and 
data  integrity  are  not  as  hard  to  control  or  manage.  In  the 
case  cf  the  stock  point  location  files  there  is  very  high 
updating  and  the  make-up  of  line  items  carrried  at  each  site 
is    very    diversified.        Since   the      data   that   pertains   to   each 
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dispersed   activity    is  centralized   at   rhat   location   th9    ':rcb- 
Isnis        of        data      integrity,  communication        cost,  and 

synchronization    cost    should    be    lowered. 

This  solution  takes  advantage  of  natural  patterns  of 
usage  and  transaction  processing  and  is  structured  around 
those  patterns.  For  example,  most  of  the  customers  at  a 
local  site  will  normally  operate  through  their  local  supply 
department  to  meet  their  needs.  These  transactions  require 
only  simple  transaction  processing.  This  makes  it  feasibls 
to  keep  the  stock  point  location  files  at  each  local  site. 
It  is  also  true  that  sometimes  the  customer  cannot  be  satis- 
fied   by    the    local   site   and    therefore      has    the   need    to    gc   off 


sxaticn      which    will      require 


complex    transaction      to 


performed.  When  this  happens  the  requestor  is  looking  for  a 
central  site  that  can  give  directions  to  a  site  that  can 
handle      the   requirement.  The      directions      that    are      being 

sought  iiill  be  handled  by  the  replica-ed  directory  at 
whichever   of  the   fiv€   sites    is   closest. 

This  information  is  obtained  by  a  user  through  th^  us^ 
of  a  "LI^■K"  command  statement  that  is  offered  by  2NFC3M,  the 
query  specification  language.  This  s-atement  offers  a 
convenient  means  of  connecting  associated  data  independent 
cf  its  location  and  without  altering  physical  files.  Using 
a  key  field,  LIKK  identifies  the  relationship  between  two  or 
lore      file      descriptions      from   the     directory.  Once      this 

process  has  taken  place  the  relationships  are  combined  so 
that  they  appear  tc  the  user  as  a  single  logical  file 
[Ref.  12].  The  three  groups  cf  files  that  have  been  previ- 
ously defined  are  shown  together  in  figure  U.U.  This  figure 
shows  some  of  the  possible  links  between  the  various 
distributed   files. 
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Figure  U.a   SrllCE  Directory. 
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Ihe  Navy  Supply  System  is  a  good  exampls  of  a  ccw-dI^x 
dist-ritu-^sd  informaticn  system.  To  solve  a  probles  wi-hir. 
this  system,  the  patterns  of  usage  and  methods  of  trans- 
acticL  processing  must  be  followed  and  used  to  answ=r  the 
questions  of  where,  how  much,  and  what  data  to  oat  at  each 
node.  The  hybrid  solution  does  this,  thus  facilitating  the 
design   and    implementation  of   a   directory. 

G.       E5NEPITS   OF    A    SPIICE   DIB2CT0RY 

The  SPLICE  directory  as  defined  above  would  put  thou- 
sands of  useful  records  at  a  wide  variety  of  users'  finger- 
tips. Through  this  on  line  directory,  a  user  could  access 
the  location  of  available  stock,  manuf actur^^r '  s  action  on 
crders,  and  even  the  status  of  their  requisitions  at 
different  sites.  Valuable  time  would  no  longer  fcs  wasted 
looking  up  and  writing  down  line  items  carried  by  a  site, 
manufacturer's  name  and  address,  or  stock  site  personnel 
contacts  every  time  they  were  needed.  The  SPLICE  directory 
would  provide  this  information  to  the  requestor.  The  direc- 
tory records  would  be  available  through  any  of  the  sixty-two 
proposed  sites,  would  be  current,  and  updatable.  Once  the 
directory  information  has  been  retrieved,  a  user  can  revise, 
create,  or  delete  a  report /record  of  the  selected  inforira- 
tion  that  is  needed  by  using  the  features  of  ENFORM,  At  the 
same  time,  the  directory  would  be  secure  by  only  allowing 
alterations   made  by    authorized    personnel. 

It  is  easy  to  see  that  the  directory  could  provide  many 
benefits  to  a  wide  variety  of  users.  The  immediate  result 
cf  providing  a  directory  would  be  that  the  directory  would 
take  the  place  of  numerous  manual  searches,  saving  tims  and 
money . 
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V.    CCNCiaSIONS 

a.       lEENIIPlCATICH    OF    3EED 

Ccnsidsring  the  diversity  cf  the  applic^ticr.  progranis 
that  will  be  tied  tc  UADES-SP  under  the  SPLICE  prcjsct, 
there  is  a  critical  r€ed  for  a  tool  to  aanage  th=  pr3pcr.isr- 
ance  cf  system  resources.  A  DDS  will  offer  the  capatilit ies 
needed  tc  control  and  manage  the  data  r9sourc3s  in  th= 
intricate  and  highly  complex  distributed  SPLICE  network 
system.  Relative  tc  this,  a  key  aspect  of  a  DDS  is  rhst  it 
provides   resource   independence. 

E.       EENZIITS 

There  are  many  benefits  that  a  SPLICE  DDS  can  provide. 
The  EES  serves  DBAs,  system  analys-s,  software  designers  ana 
progra^irers  by  reguiring  definitions  of  system  data 
elements,  files,  programs  and  reports.  Conversion  to 
uniform  resource  description  standards  allows  systems  within 
the  SPLICE  network  tc  interface  easier  and  more  freely.  By 
establishing  standards  of  data  definitions  and  descriptions 
for  applications  programs  throughout  the  SPLICE  system,  the 
DDS  serves  as  the  focal  point  for  future  analysis  and 
design.  Using  a  DDS,  data  can  be  managed  to  the  best  advan- 
tage fcr  the  existing  information  system  and  can  be  effec- 
tively redeployed  to  ireet  changing  information  requirements. 
The  DES  can  be  used  tc  generate  test  data  and  check  results 
before  allowing  chanced  programs  tc  replace  the  production 
versicns , 
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C.       SINOFSIS 

This  thssis  reviewed  th^  current  status  of  ths  SIALICS 
DDS  ar.d  proposed  a  TANDE"  DDS  for  SPLICE.  Basic  concrpts 
and  ccnsiderations  in  evaluating  a  DDS  were  discissec  and 
these  fundamental  principles  were  applied  to  -he  TANCSM  Data 
Dictionary  and  a  preliminary  Directory  design  based  upon  the 
TANDEM  EEMS.  A  brief  comparison  was  made  of  the  TANDEM  Data 
Dictionary   and    other   commercial   products. 

The  TANDEM  Data  Dictionary  is  essentially  a  data  element 
dictionary.  It  is  a  DBMS -application  approach  to  a  DDS. 
The  product  does  not  have  directory  capabilities  at  this 
time.  The  dictionary  is  an  active/dependent  system  which 
would  raquire  that  SPLICE  system  components  depend  upon  -he 
dictionary  for  their  data.  Its  usefulness,  in  its  present 
form,  would  primarily  be  as  a  tool  for  manipulating  infcrrna- 
tion      about      data      elements      in      a      database.  The      TANDEM 

dictionary  operates  effectively  as  a  conversion  facility  for 
three  different  programming  languages  as  well  as  for  the  DDL 
compiler.  By  placing  -he  data  definitions  and  data  struc- 
tures in  a  single  language,  the  DBA  gains  control  over  th=» 
database  design  and  implementation.  Considering  the  volume 
of  data  in  SPLICE  and  its  complexity,  this  would  b^  an 
advantageous  feature. 

E.       FINAL    COMMENT 


A  DDS  is  a  powerful  information  management  tool  with 
potential,  positive  payoff  for  the  SPLICE  project.  It  is 
important  to  no-^e  that  the  EDS  can  only  improve  system 
productivity  and  accuracy  if  its  design  potential  is 
exploited.  As  a  minimum,  it  must  indicate  what  and  where 
data  is  stored,  when  and  hew  updates  are  handled  and  which 
applications  programs  are  accessed.  A  DDS  implemented  to 
perform  these  functions  clearly  provides  a  great  deal  of 
autcniated    system   control. 
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Naturally  thare  ars  soms  drawbacks  in  employing  a  DDS. 
a  DDS  implies  system  cvsrhead  and  niaintsnanca  as  well  as  an 
initial  hurder.  on  database  management  personnel.  Hcv<<=7sr, 
proper  planning  and  early  crganization-wid^  commitnent  to 
managing  data  as  a  i-=source  will  create  a  climate  in  which 
an  active  EDS  can  facilitate  orderly  data  processing  while 
avoiding  chaotic  data  management.  A  DDS  can  be  a  valuable 
tool  in  the  management  of  distributed  data  for  the  SrLICS 
project. 


in 


IIST   OF    BEFERSNCES 


1.  Fleet  Material  Suooort  Office,  Department  of  th?  Navy 
Document  Mo.  F^UlO-OO  1-9260-FD-SU01 ,  Stock  icint 
Lcaistics  Intecrated  Co  a  manic  at  ions  '^nvircn.Tien^ 
IIIII^IT/    Funcl3cnaI'"Ts£cricgipn,    1   "l^ay    19  8U.    ~ 

2.  U.S.  Navy  Fleet  Material  Supper-  Office^  Snvircnmsnt 
Division:  Code  9U41,  Stock  Point  Loaistics  Integrated 
Ccmmunica  tion_s    Fnviro  nmen^    i'^'ZL.Z.^ZT > ''~^2l^'±^- 3.  lesion  ^ 


19~"HafcE~T-g7^7 


3. 


a.  Naval        Postgraduate      School        Report        NP3-54-82-003, 

Furctional  Desion  cf  s.  Local  Area  Netvcrk  fo^  the 
Sfccx  7oinl  "To^isrics  "In^'^H-a^ed  ^oaaun  icaticns 
Inyif cnmen~,    by  I7.Fr""ScIine  13 e win's,    T5ecem5er    lysi 

5.  National  Eureau  of  Standards  Special  Publication 
500-3,  I^chnical  P  rof lie  of  Seven  Data  Element 
Dictici^r  v25i.£f£52LZ~lZ§l^iES»    February    1977  ""  ^ 

6.  Allen,  F.W.,  Lccmis,  M.E.S.,  and  Mannino,  M.V.,  "The 
Integrated  Dictionary/Directory  Svstem, "  Computing 
Surveys,    June    1982. 

7.  Naval  Postgraduate  School  Report  NPS54-S3-01 5,  A 
Distributed    .         O^eratina  Systera_  Design  ana 


_  £  _  ^V-o 


8.  Data  Dictionary  Systems  Workina  Party  (1977),  "The 
British  Computer  Society  Data  Dictionary  Systems 
Report,"    SIGMOC    Record,    vol.    9,,  no.    4,    December    1977 

9.  Teichroew,  D.  and  Kershey,  E. ,  "PSL/FSA:  A 
Computer-aided  Technique  for  Structured  Documentation 
and  Analysis  of  Information  Processing  Svstems,"  IEEE 
Transactions  on  Software  Engineering,  Vol  SE3-NcTT, 
3anuary"T?Tr,"TI1-irB7 

10.  Fleet  Jlaterial  Supoort  Office,  Deoartment  of  the  15avy, 
Document  No.  F94L0 -9260-00 1-33-SU0 1 ,  Stock  Point 
Loaistics  L^^JQi^^l^J  Communications  "EnvTrormen? 
imi^irr    Sys^em~jpecifi.ca^ion,"-2   February    T9H1. 

11.  TANDEI?  Computers  Incorporated,  inscribe  (TM) 
Prcgramming    Manual,    April    ^981 

75 


16. 


TANDEM      CoffiDuters      Incorporated,      Enfcroi      (Tm)          Us=rs 
Guid^,   October    1982  —  

TANEEM        Ccmpntprs      I nccraorated ,  ^"^-o.         Dqf  ir.i-^  lor. 

Lar.quaQg     (DDL)     Eroara mminq    Manual,    DeceiBer    T^'HT 


•  / 


1U.         Lefkovits,    H.C.,      Sibley,      E.  H.      and    L^fkovits,      3.1 

Information      Resource/Data      Dictionary     lU^JiUS,         QED 
Tnlor  niat-ion   Sciences,    Inc.,    T'^ol 

15.         Krcsnke,    David,    Database    Processing,      Science    Bes=arch 
Associates,    Inc.7  "^"977 


Mar"^in,      James,        Desion   and    Strateaj^      for    Distri  rated 
P§1§   Processinc,    PrenIic3-T!aiT,    IncT,    1^1 


17.         Pooch,  U.W.^  Greene,  W.H,  and  J^oss, 

G.  G.  ,  Teleccmmunications   and   Ner.  working.    Little,      Brown 
&    Company   ItTanaHa)    Elniite^,    T"9H3 


76 


INITIAL   DISTBIBOTION    LIST 


1. 
2. 
3. 

a. 

5. 
6. 
7. 

8. 
9. 
10. 


Eefcr.se  Technical   Inf ornia-ticn    Csr.ter 
CaiD€rcr.  Sta-^-ion 
Alexandria,    Virginia   2213U 

litrary.    Code    0  142 

Naval    ircstgraduate    School 

Monterey,    Califcrria   939a3 

Naval    Postgraduate    School 

Ccmcuter   Technolccies    Curriculum   Office 

Cods    37 

Monterey,    California    9  39U3 

Assistant    Professor   Dan    B,    Dolk,    Code    54Dk 
EeDartment    or    A cninist rative   Sciences 
Naval    Postgraduate    School 
Monterey,    Calif crnia   9  39a3 


Cop, 
2 


Code    suss 
ences 


Professor    Ncrman   F.    Sc hneidewind. 
Department    of    Administrative    Scie 
Naval    Postaraduate   School 
Monterey,    California   939U3 

Ccmirander    Tom    Picoski,    Code    G-30D 
Naval    Security    GfouD 
38  01    Nebraska    Ave.    NW 
Washington,    D.C.    20390 

lieutenant    Colonel    Joseph    P.    Mullane,    USMC 

Code   0  309 

Marine   Corps   Representative 

Naval    Postgraduate   Schccl 

Monterey,    Califcrnia   93943 

Cc-ntrandant    of   the   .larine   Corps    (Code   CC) 
Headguarters   Marine   Corps 
Washington,    D.C.    20380 

lieutenant    David  C.    Ruff,    SC,    USN 

Route    6 

Tupelo,   Mississippi    3S801 

Captain  James    H.   Johnson,    534-60-9291/3002    USMC 
Headguarters   Marine   Corps    (MCC    009) 
fcashincton,    D.C.    20380 


77 


/^/'^^^ 


Thesis 

R8UU2 

c.l 


Ruff  I 

A  preliminary  DDS  ■ 
design  for  SPLICE  based 
upon  the  TMDEM  DBMS. 


AUG  ee 


ed 


3  17  6  0 
327  15 


Thesis 

R81+ii2 

c.l 


lUlSkl 


Ruff 

A  preliminary  DDS 
design  for  SPLICE  based 
upon  the  TANDEM  DBMS. 


